Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1996-11-20
2001-10-30
Maung, Zarni (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
Reexamination Certificate
active
06311227
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a procedure calling method and more particularly, to a procedure calling method that performs procedure calling in the object-oriented technology.
2. Description of the Prior Art
A procedure calling method which has been most widely accepted in the object-oriented technology is that which uses a paired information table for procedure names and the addresses of procedures represented by the names. The information table is termed a “procedure assignment table”. A typical example of the procedures is a function.
An example of the conventional procedure calling methods of this sort is shown in FIG.
1
. As shown in
FIG. 1
, this method contains a procedure name acquisition step S
101
, a procedure assignment table reading step S
102
, a procedure address judging step S
103
, a procedure address acquisition step S
104
, a procedure execution step S
105
, and an execution error output step S
106
.
With the conventional procedure calling method of
FIG. 1
, procedure assignment tables, each of which contains sets of a name and address of a procedure, are previously prepared by a translation system (such as a compiler) of the source program. An example of the procedure assignment table is shown in
FIG. 2
, in which the reference numeral
81
represents a procedure assignment table of the class A1, and the reference numeral
82
represents a procedure assignment table of the class A.
If a procedure name is specified as the key in the step S
101
, a corresponding procedure address listed in the corresponding procedure assignment table (for example, the table
81
or
82
in
FIG. 2
) can be obtained through the seeps S
102
to S
104
. Therefore, if a procedure assignment table is prepared for each class (each of the classes A and A1 in FIG.
2
), different processes can we executed with the same procedure name in the tables of the different classes.
When a plurality of procedure assignment tables are provided for a single procedure name, the pertinent procedure assignment table may be determined in executing the program by the execution code prepared by the translation system such as a compiler.
For example, when a derived class is used by defining it from the base class which is equivalent to the root of the inherited hierarchy tree, each of the procedure assignment tables, the number of which is the same as that of the derived classes, is provided with an entry of the same procedure name as that of the base class. In this case, the source program has a statement to which a certain procedure P for an object variable V is applied. If the procedure P is redefined in the derived class, the procedure assignment table is found out and read on the basis of the class information including the class name of the object to be substituted into the object variable V on execution (see step S
102
in FIG.
1
). Further, a code to determine the execution code for the correct procedure P (see steps S
104
and S
105
in
FIG. 1
) is generated by the compiler.
With the conventional procedure calling method as stated above, in which the procedure assignment table is determined for each class name, the procedure assignment table cannot be changed over with an application program. As a result, a problem that it is difficult for an appropriate procedure to be able to be mutually called safely between separately-prepared application programs occurs.
For example, as shown in
FIG. 2
, it is supposed that an application program contains the definition of the base class A, and another application program contains the definition of the base class A and the definition of a derived class A1 thaw uses the definition of the class A. It is also supposed that the address of the execution code corresponding to a procedure name “func i” of the derived class A1 is set as the address of the execution code for a procedure name “func i” of the base class A, i.e., “$A::func i”, as show-n in the procedure assignment tables
81
and
82
of the classes A1 and A.
If the base class A is updated independently of the derived class A1, the execution code stored in the address “$A::func i” in the procedure assignment table
82
of the base class A may be replaced. Therefore, it cannot be assured that the procedure “func i” of the derived class A1 always provides the operation or behavior that was expected by the definition of the class A1.
To avoid such a problem, the Microsoft Component Object Model adopts a procedure calling method as shown in FIG.
3
.
For this procedure calling method of
FIG. 3
, the address of the function corresponding to the procedure for an object in an application program is not determined by the compiler; but determined through the “QueryInterface” procedures in the special function tables IUnKnown
911
and
921
, to which all function tables must be related. These function tables are equivalent to the above-described procedure assignment tables.
With the procedure calling method shown in
FIG. 3
, the programmer provides an application program so that the “Interface” is defined as a group of functions or procedures in the function table or procedure assignment table, and the reference (i.e., pointer) to the “Interface” corresponds to the return value of the “QueryInterFace” procedure.
In the example in
FIG. 3
, to allow the function “func i” stored in the procedure assignment table
912
of the derived class A1 to use the execution code for the function, “func i” stored in the procedure assignment table
922
of the base class A, the programmer must provide the “QueryInterface” procedure in the “Iunknown” table
911
related to the class A1 so that the “interface” obtained by the “QueryInterFace” procedure in the “Iunknown” table
921
related to the class A is returned. In other words, in providing the “QueryInterface” procedure for a function listed in the “Iunknown” function table: the programmer must make an explicit statement so that the code to be reused is related.
With the conventional procedure calling method of
FIG. 3
, since such a contrivance as checking the versions of the class A in
FIG. 3
is allowed in making the relationship of the code to be reused, the programmer is able to avoid the above problem in the conventional procedure calling method as shown in FIG.
2
.
However, for a function that is certain to be reusable, the programmer must retrieve the code for making the relationship of the code to be reused, and explicitly provide or state it. This causes a problem of an increased load imposed on the programmer.
In addition, because the “Interface” is a group of functions, even when an execution code of the base class (the class A in
FIG. 3
) is to be reused for only a single function in the “Interface” group, the entire “Interface” must be reused for only the single function, or the same code as that of the base class must be newly stated for its reuse. This causes another problem that efficient reuse of the code is difficult.
SUMMARY OF THE INVENTION
Accordingly, an object of the present invention is to provide a procedure calling method which makes it possible that a procedure can be mutually called safely between separately prepared application programs.
Another object of the present invention is to provide a procedure calling method that allows to safely and efficiently build up an information processing system which uses the object-oriented technology and which includes the combination of separately-prepared application programs.
The above objects together with others not specifically mentioned will become clear to those skilled in the art from the following description.
A procedure calling method according to a first aspect of the present invention uses a procedure assignment table having paired information about procedure name and procedure address, which includes the following steps.
First, whether the address of a procedure corresponding to a called procedure name is included in a first procedure assignment table or not is judged. When the address of the procedure corresponding to t
Foley & Lardner
Fourson Gary Scott
Maung Zarni
NEC Corporation
LandOfFree
Procedure calling method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Procedure calling method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Procedure calling method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2583803