EP1157330A1 - Method and system for implementing virtual functions of an interface - Google Patents
Method and system for implementing virtual functions of an interfaceInfo
- Publication number
- EP1157330A1 EP1157330A1 EP00910074A EP00910074A EP1157330A1 EP 1157330 A1 EP1157330 A1 EP 1157330A1 EP 00910074 A EP00910074 A EP 00910074A EP 00910074 A EP00910074 A EP 00910074A EP 1157330 A1 EP1157330 A1 EP 1157330A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- interface
- class
- forwarding
- virtual
- macro
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L12/2807—Exchanging configuration information on appliance services in a home automation network
- H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/465—Distributed object oriented systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T1/00—General purpose image data processing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- H—ELECTRICITY
- H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
- H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
- H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
- H05B47/10—Controlling the light source
- H05B47/155—Coordinated control of two or more light sources
-
- H—ELECTRICITY
- H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
- H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
- H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
- H05B47/10—Controlling the light source
- H05B47/175—Controlling the light source by remote control
- H05B47/18—Controlling the light source by remote control via data-bus transmission
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/2803—Home automation networks
- H04L2012/2847—Home automation networks characterised by the type of home appliance used
- H04L2012/2849—Audio/video appliances
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/75—Indicating network or usage conditions on the user display
-
- H—ELECTRICITY
- H05—ELECTRIC TECHNIQUES NOT OTHERWISE PROVIDED FOR
- H05B—ELECTRIC HEATING; ELECTRIC LIGHT SOURCES NOT OTHERWISE PROVIDED FOR; CIRCUIT ARRANGEMENTS FOR ELECTRIC LIGHT SOURCES, IN GENERAL
- H05B47/00—Circuit arrangements for operating light sources in general, i.e. where the type of light source is not relevant
- H05B47/10—Controlling the light source
- H05B47/165—Controlling the light source following a pre-assigned programmed sequence; Logic control [LC]
Definitions
- the described technology relates generally to object-oriented programming techniques and more specifically to a system for automatically implementing virtual functions.
- Object-oriented prograrnming techniques allow for the defining of "interfaces" by which objects can expose their functionality independently of the implementation of the functionality.
- an interface is defined by an abstract class whose virtual functions are all pure. A pure virtual function is one that has no implementation in the class. Thus, an interface defines only the order of the virtual functions within the class and the signatures of the virtual functions, but not their implementations.
- class IShape class IShape
- This interface has three virtual functions: draw, save, and clear.
- the save function of the IShape interface may have an implementation that saves the shape information to a file on a local file system.
- Another implementation may save the shape information to a file server accessible via the Internet.
- class that implements the interfaces inherits the interface.
- class Shape IShape
- the first line of the class definition indicates by the ": IShape" that the Shape class inherits the IShape interface.
- the ellipses between the braces indicate source code that implements the virtual functions.
- the Shape class in addition to providing an implementation of the three virtual functions of the IShape interface, also defines a new virtual function "internal save,” which may be invoked by one of the implementations of the other virtual functions.
- the Shape class also has defined two integer data members, x and y.
- Typical C++ compilers generate virtual function tables to support the invocation of virtual functions.
- a C++ compiler When an object for a class is instantiated, such a C++ compiler generates a data structure that contains the data members of the object and that contains a pointer to a virtual function table.
- the virtual function table contains the address of each virtual function defined for the class.
- Figure 1 illustrates a sample object layout for an object of the Shape class.
- the object data structure 101 contains a pointer to a virtual function table and the data members x and y.
- the virtual function table 102 contains an entry for each virtual function. Each entry contains the address of the corresponding virtual function.
- the first entry in the virtual function table contains the address of the draw function 103.
- the order of the references in the virtual function table is the same as defined in the inherited interface even though the Shape class specifies these three functions in a different order. In particular, the reference to the draw function is first, followed by the references to the save and clear functions.
- the C++ compiler generates code to invoke virtual functions indirectly through the virtual function table.
- the following is C++ code for invoking a virtual function.:
- Shape* pShape new Shape; pShape->save();
- the pointer pShape points to an object in memory that is of the Shape class.
- the compiler When compiling this invocation of the virtual function, the compiler generates code to retrieve the address of the virtual function table from the object, to add to the retrieved address the offset of the entry in the virtual function table that contains the address of the function, and to then invoke the function at that calculated address.
- a routine that uses an implementation may define a formal argument that is a pointer to the IShape interface.
- the developer of the routine can be unaware that the implementation is actually the Shape class.
- a program that invokes the routine would type cast a pointer to the object of the Shape class to a pointer to the IShape interface. So long as the pointer points to a location that contains the address of the virtual function table and the virtual function table contains the entries in the specified order, the invoked routine can correctly access the virtual functions defined by the IShape interface:
- class Almp A virtual void Al () ⁇ ... ⁇ ; virtual void A2Q ⁇ ... ⁇ ;
- classes A and B are interfaces.
- Interface A defines virtual function Al
- interface B defines virtual function Bl.
- Class Almp is an implementation of interface A and defines a new virtual function A2.
- Class Blmp is an implementation of interface B that inherits the implementation of interface A, which is class Almp.
- class Blmp inherits multiple classes: class Almp and interface B.
- Some C++ compilers have the option of merging the virtual function tables of multiple base classes into a single virtual function table in the derived class or of generating separate virtual function tables for each base class.
- One difficulty arises if the virtual function tables of the base classes are merged in the derived class.
- Figure 2 illustrates the difficulty when the virtual function tables are merged.
- the object layouts 201 and 202 illustrate the order of the virtual functions within the virtual function tables. (Since interfaces A and B are abstract classes, objects of these classes cannot actually be instantiated.) To allow type casting as described above, an implementation of interface B needs to provide a virtual function table with entries in the same order as shown in object layout 202, that is with the entry for virtual function (0 Al followed immediately by the entry for virtual function Bl.
- the virtual function table of class Ahnp is shown by object layout 203.
- Object layout 204 illustrates the virtual function table for class Blmp when the virtual function tables are merged.
- This virtual function table for class Blmp illustrates the order of the entries to be virtual functions Al, A2, and Bl. If a pointer to an object of class Almp is type cast to a pointer to interface B, then the virtual function table would not have the entries in the order as specified by the interface B. In particular, the entry for virtual function Al is not immediately followed by the entry for virtual function Bl.
- a C++ compiler could have reordered in entries in the virtual function table within object layout 204 to be virtual functions Al, Bl, and A2. In which case, the type casting for interface B would work. However, the type casting from a pointer to a class Blmp object to a class Almp object would be incorrect because the class Almp defines that the entry for virtual function Al is immediately followed by the entry for virtual function A2. Thus, a C++ compiler cannot define a single virtual function table that satisfies the virtual function table ordering of both interface B and class Almp.
- Figure 3 illustrates the object layouts with separate virtual function tables.
- the object layout 304 for class Blmp has two virtual function tables.
- the first virtual function table has the order of entries to be virtual functions Al and A2, which is consistent with the ordering for class Almp.
- the second virtual function table has the order of entries to be virtual functions Al and Bl, which is consistent with the ordering for interface B.
- the difficulty arises because the developer of class Blmp, who wants to reuse the implementation of interface A, which is class Almp, must provide an implementation for each virtual function of interface A within class Blmp. (These multiple implementations can be avoided by virtually inheriting interface A.
- Class Blmp Almp, B ⁇ virtual void Bl() ⁇ ... ⁇ ; virtual void Al() ⁇ return AImp::Al() ⁇ ⁇
- virtual fimction Al invokes the implementation of virtual function A 1 in the class Almp.
- this implementation is straightforward, problems arise when interface A is changed. For example, if a new virtual function A3 is added to interface A, then the developer of the class Blmp would need to change the class definition to include an implementation of the new virtual function A3.
- the changing of the class definition in this example may not be difficult, the changing of class definitions in systems that use complex inheritance hierarchies and many virtual functions can present difficulties. It would be desirable to have a technique which would avoid the difficulties of having to change class definitions when a new virtual function is added to an interface.
- a forwarding system adds to the class for each virtual fimction a forwarding implementation of that virtual function.
- the forwarding implementation forwards its invocation to the implementation of that the virtual function in the implementing class.
- the forwarding system implements a special forwarding instruction that specifies the interface and implementing class. A developer of a class that inherits the interface and the implementing class inserts the forwarding instruction into the class definition.
- the forwarding system When the forwarding system encounters such an instruction during compilation of the class definition, the forwarding system provides an implementation of each virtual fimction of the interface that forwards its invocation to a corresponding virtual function in the implementing class. The forwarding system also forwards virtual functions of any direct or indirect base interface of the interface to the implementing class.
- Figure 1 illustrates a sample object layout for an object of the Shape class.
- Figure 2 illustrates the difficulty when the virtual function tables are merged.
- Figure 3 illustrates the object layouts with separate virtual function tables.
- Figure 4 is a block diagram of an example implementation of the forwarding system.
- Figure 5 is a block diagram illustrating a computer system for practicing the forwarding system.
- Figure 6 is a flow diagram illustrating an example implementation of a routine to automatically add forwarding macros to interface definitions.
- Embodiments of the present technology provide a method and system for automatically generating implementations of virtual fimctions of interfaces.
- the system generates the implementations so that each virtual function forwards its invocation to a virtual function that provides an implementation.
- the forwarding system implements a special forwarding instruction that specifies an interface and an implementing class.
- a developer of a class that inherits the interface and the implementing class inserts the forwarding instruction into the class definition.
- the forwarding system provides an implementation of each virtual function of the interface that forwards its invocation to a corresponding virtual function in the implementing class.
- the forwarding system also forwards virtual fimctions of any direct or indirect base interface of the interface to the implementing class.
- the forwarding system automatically detects that no implementation has been provided for the interface and inserts a forwarding implementation to the implementing class.
- the forwarding system is implemented by adapting a compiler to recognize a special forwarding instruction and to automatically insert and implementation of the virtual functions.
- the forwarding system may be implemented using standard macros that are preprocessed by a compiler, such as a C++ compiler.
- the macro implementation of the forwarding system is referred to as the "macro system.”
- the macro system defines a forwarding macro for each interface that provides an implementation of each virtual function that forwards the invocation of the virtual function to an implementation of that virtual function in a class whose name is passed as a parameter to the macro. The following illustrates the forwarding macro that is defined for class A: class A
- the "#define” indicates that a macro is being defined, the "SforwardATo” is the name of the macro, and the "interface” is the name of a parameter that is passed when the macro is expanded.
- the body of the macro is "virtual void Al() ⁇ return interface##::Al() ⁇ ;” where "interface##” indicates that the passed parameter is to be substituted.
- the macro definition is terminated by a statement that does not end with a " ⁇ ". In other words, a " ⁇ " at the end of a statement within the macro indicates that the macro continues onto the next line.
- the parameter such as "Imp”
- the result is: virtual void Al() ⁇ return Imp::Al() ⁇ ;
- interface B which is class Blmp
- an implementation of virtual function Al is provided that forwards its invocation to the implementation of class Almp.
- class Blmp Almp, B ⁇ virtual void Bl () ⁇ ... ⁇ ; $forwardATo(AImp)
- class Blmp Almp
- the SforwardATo macro is redefined to add statements that are forwarding implementations of the new virtual functions. Because class Blmp calls that macro, when the macro is expanded, the definition of class Blmp will include forwarding implementations of the new virtual functions. Thus, once a developer adds a forwarding macro to class Blmp modifications to interface A are automatically reflected in class Blmp.
- forwarding macro needs to include statements that will generate forwarding implementations of each virtual function in inherited interfaces.
- An implementing class that inherits interface B need only expand the forwarding macro for interface B, which automatically expands the forwarding macro for interface A.
- interface C which is class Clmp, that uses the forwarding macro of interface B: class C : B
- class Clmp class Clmp : Blmp, C ⁇ virtual void Cl () ⁇ ... ⁇ ; virtual void Al() ⁇ return BImp::Al() ⁇ ; virtual void Bl() ⁇ return BImp::Bl() ⁇ ;
- a difficulty with the naming convention of these forwarding macros is that an implementation needs to know of any directly inherited interface of its directly inherited interface.
- interface C which is class Clmp
- interface B is directly inherited by interface C so that the appropriate forwarding macro, "SforwardBTo," can be used.
- One embodiment of the macro system overcomes this difficulty by defining an additional parent class forwarding macro for each interface that inherits an interface.
- the parent class forwarding macro has a name that is based solely on the interface for which it is defined, but calls the forwarding macro for its directly inherited interfaces.
- the following definition of interface B illustrates the parent class forwarding macro: class B : A
- the parent class forwarding macro is "SforwardBParentClassTo.” This macro calls the forwarding macro for its inherited interface A.
- An implementing class can call the parent class forwarding macro of its directly inherited interface rather than calling the forwarding macro of an indirectly inherited interface. Thus, the implementation need not be aware that an inherited interface happens to inherit another interface.
- class Blmp Almp, B ⁇ virtual void Bl() ⁇ . . ⁇ ; $forwardBParentClassTo(AImp)
- class Blmp Almp, B
- any interface regardless of whether it currently inherits another interface can provide an implementation of the parent class forwarding macro. If the interface does not currently inherit another interface, then the parent class forwarding macro would be defined to be empty. Thus, when such a parent class forwarding macro is expanded, no statements are inserted into the calling class definition and the expansion would have no effect. If, however, the interface is eventually changed to inherit another interface, then the parent class forwarding macro would be redefined to call the forwarding macro of the inherited interface. The change in the parent class forwarding macro would automatically the reflected when the parent class forwarding macro is expanded in the calling class definition.
- FIG. 4 is a block diagram of an example implementation of the forwarding system.
- the forwarding system may be implemented as part of a compiler or as a preprocessor to a compiler.
- the process forwarding instruction routine is invoked when the forwarding system encounters a special forwarding instruction, which specifies an interface and an implementing class or automatically detects such a situation.
- the routine inserts, into the class definition that inherits the interface and that inherits the implementing class, a forwarding implementation for each virtual function of the interface.
- the routine then recursively calls itself to insert forwarding implementations for virtual functions of any indirectly inherited interfaces of the interface.
- the routine loops inserting forwarding implementations for each virtual function of the interface.
- step 401 the routine selects the next virtual function of the interface.
- step 402 if all the virtual functions have aheady been selected, then the routine continues at step 404, else the routine continues at step 403.
- step 403 the routine inserts a forwarding implementation of the selected virtual function that forwards its invocation to the implementing class.
- step 404 if the interface has an inherited interface (i.e., a base interface), then the routine continues at step 405, else the routine returns.
- step 405 the routine recursively invokes the process forwarding instruction routine passing the base interface and the implementing class. The routine then returns.
- FIG. 5 is a block diagram illustrating a computer system for practicing the forwarding system.
- the computer system 500 includes a central processing unit 501, I/O devices 502, and memory 503.
- the I/O devices may include computer readable media, such as a hard disk or a flexible disk, on which components of the forwarding system may be stored.
- the forwarding system that is stored in memory is the macro system.
- the forwarding system comprises an add forwarding macro component 505.
- the add forwarding macro component inputs interface definitions 504 and outputs modified interface definitions 506.
- the add forwarding macro component inserts the forwarding macro and the parent class forwarding macro into the interface definitions.
- the compiler preprocessor 508 inputs the modified interface definitions 506 and class definitions that have calls to the macros 507.
- FIG. 6 is a flow diagram illustrating an example implementation of a routine to automatically add forwarding macros and parent class forwarding macros to interface definitions.
- This routine is passed an interface definition and inserts macro definitions for the forwarding macro and the parent class forwarding macro.
- the routine inserts a statement "#define $forward ⁇ class>To(interface) ⁇ " into the interface definition. This statement starts the definition of the forwarding macro. The " ⁇ class>" is replaced by the name of the interface.
- step 602 if the interface inherits a base interface, then the routine continues that step 603, else the routine continues that step 604.
- step 603 the routine inserts the statement "$forward ⁇ baseclass>To(interface); ⁇ ".
- the " ⁇ baseclass>” is replaced by the name of the inherited interface.
- This statement calls the forwarding macro of the inherited interface.
- steps 604-606 the routine loops adding forwarding implementations for each virtual function of the interface.
- step 604 the routine selects the next virtual function.
- step 605 if all the virtual functions have aheady been selected, then the routine continues at step 607, else the routine continues at step 606.
- step 606 the routine adds the forwarding implementation of the selected virtual function and loops to step 606 to select the next virtual function.
- step 607 the routine adds a termination for the macro definition. The termination may be accomplished by inserting a blank line.
- step 608 the routine adds the statement "#define $forward ⁇ class>ParentClassTo(interface) ⁇ ". This statement defines the parent class forwarding macro.
- step 609 if the interface inherits a base interface, then the routine continues its step 610, else the routine continues that step 611.
- step 610 the routine adds the statement "$forward ⁇ baseclass>To(interface) ⁇ ". This statement calls the forwarding macro of the base interface. If, however, the interface inherits no base interface, then the parent class forwarding macro is empty.
- step 611 the routine adds a termination of the macro definition and completes.
Abstract
A method to support dynamic interconnection between audio visual devices in a home automation system, where each hardware device has a mirror image in a computer system represented by an object. These objects, and their ports (i.e. input and output plugs) are organised in a hierarchical way. The flow of data (stream) from one device to another one is driven by the computer system through a network, a session and a management system, which respectively deal with temporal connections, virtual circuits, (virtual paths) and streams between the components.
Description
METHOD AND SYSTEM FOR IMPLEMENTING VIRTUAL FUNCTIONS OF AN INTERFACE
TECHNICAL FIELD
The described technology relates generally to object-oriented programming techniques and more specifically to a system for automatically implementing virtual functions.
BACKGROUND
Object-oriented prograrnming techniques allow for the defining of "interfaces" by which objects can expose their functionality independently of the implementation of the functionality. In the C++ progranrming language, an interface is defined by an abstract class whose virtual functions are all pure. A pure virtual function is one that has no implementation in the class. Thus, an interface defines only the order of the virtual functions within the class and the signatures of the virtual functions, but not their implementations. The following is an example of an interface: class IShape
{ virtual void draw(int x,y):=0; virtual void save(char filename)=0; virtual void clear(int x,y)=0; }
This interface, named "IShape," has three virtual functions: draw, save, and clear. The "=0" after the formal parameter list indicates that each virtual function is pure. Concepts of the C++ prograrnrning language that support object-oriented prograrnming are described in "The Annotated C++ Reference Manual," by Ellis and Stroustrup, published by Addison- Wesley Publishing Company in 1990, which is hereby incorporated by reference.
Once an interface is defined, programmers can write programs to access the functionality independent of the implementation. Thus, an implementation can be changed or replaced without having to modify the programs that use the interface. For example, the save function of the IShape interface may have an implementation that saves the shape
information to a file on a local file system. Another implementation may save the shape information to a file server accessible via the Internet.
To ensure that an implementation provides the proper order and signatures of the functions of an interface, the class that implements the interfaces inherits the interface. The following is an example of a class that implements the IShape interface. class Shape : IShape
{ virtual void save(char filename) { ... } ; virtual void clear(int x,y){ ... }; virtual void draw(int x,y) {... }; virtual void internal_save(){ ... } ; int x; int y;
}
The first line of the class definition indicates by the ": IShape" that the Shape class inherits the IShape interface. The ellipses between the braces indicate source code that implements the virtual functions. The Shape class, in addition to providing an implementation of the three virtual functions of the IShape interface, also defines a new virtual function "internal save," which may be invoked by one of the implementations of the other virtual functions. The Shape class also has defined two integer data members, x and y.
Typical C++ compilers generate virtual function tables to support the invocation of virtual functions. When an object for a class is instantiated, such a C++ compiler generates a data structure that contains the data members of the object and that contains a pointer to a virtual function table. The virtual function table contains the address of each virtual function defined for the class. Figure 1 illustrates a sample object layout for an object of the Shape class. The object data structure 101 contains a pointer to a virtual function table and the data members x and y. The virtual function table 102 contains an entry for each virtual function. Each entry contains the address of the corresponding virtual function. For example, the first entry in the virtual function table contains the address of the draw function 103. The order of the references in the virtual function table is the same as defined in the inherited interface even though the Shape class specifies these three functions
in a different order. In particular, the reference to the draw function is first, followed by the references to the save and clear functions.
The C++ compiler generates code to invoke virtual functions indirectly through the virtual function table. The following is C++ code for invoking a virtual function.:
Shape* pShape = new Shape; pShape->save();
The pointer pShape points to an object in memory that is of the Shape class. When compiling this invocation of the virtual function, the compiler generates code to retrieve the address of the virtual function table from the object, to add to the retrieved address the offset of the entry in the virtual function table that contains the address of the function, and to then invoke the function at that calculated address.
The inheritance of interfaces allows for references to objects that implement the interfaces to be passed in an implementation independent matter. A routine that uses an implementation may define a formal argument that is a pointer to the IShape interface. The developer of the routine can be unaware that the implementation is actually the Shape class. To pass a reference to an object of the Shape class, a program that invokes the routine would type cast a pointer to the object of the Shape class to a pointer to the IShape interface. So long as the pointer points to a location that contains the address of the virtual function table and the virtual function table contains the entries in the specified order, the invoked routine can correctly access the virtual functions defined by the IShape interface:
Although the use of interfaces facilitates the development of programs that use and implement interfaces, difficulties do arise. The following C++ source code illustrates one of these difficulties. class A
{ virtual void A1()=0;
}
class B : A virtual void Bl ()=0;
class Almp : A virtual void Al (){... }; virtual void A2Q {... };
class Blmp : Almp, B virtual void B !(){... };
In this example, classes A and B are interfaces. Interface A defines virtual function Al, and interface B defines virtual function Bl. Class Almp is an implementation of interface A and defines a new virtual function A2. Class Blmp is an implementation of interface B that inherits the implementation of interface A, which is class Almp. Thus, class Blmp inherits multiple classes: class Almp and interface B.
Some C++ compilers have the option of merging the virtual function tables of multiple base classes into a single virtual function table in the derived class or of generating separate virtual function tables for each base class. One difficulty arises if the virtual function tables of the base classes are merged in the derived class. Figure 2 illustrates the difficulty when the virtual function tables are merged. The object layouts 201 and 202 illustrate the order of the virtual functions within the virtual function tables. (Since interfaces A and B are abstract classes, objects of these classes cannot actually be instantiated.) To allow type casting as described above, an implementation of interface B needs to provide a virtual function table with entries in the same order as shown in object layout 202, that is with the entry for virtual function (0 Al followed immediately by the entry for virtual function Bl. A problem arises when the implementation of interface A, which is class Almp, defines a new virtual function, such as virtual function A2. The virtual function table of class Ahnp is shown by object layout 203. Object layout 204 illustrates the virtual
function table for class Blmp when the virtual function tables are merged. This virtual function table for class Blmp illustrates the order of the entries to be virtual functions Al, A2, and Bl. If a pointer to an object of class Almp is type cast to a pointer to interface B, then the virtual function table would not have the entries in the order as specified by the interface B. In particular, the entry for virtual function Al is not immediately followed by the entry for virtual function Bl. A C++ compiler could have reordered in entries in the virtual function table within object layout 204 to be virtual functions Al, Bl, and A2. In which case, the type casting for interface B would work. However, the type casting from a pointer to a class Blmp object to a class Almp object would be incorrect because the class Almp defines that the entry for virtual function Al is immediately followed by the entry for virtual function A2. Thus, a C++ compiler cannot define a single virtual function table that satisfies the virtual function table ordering of both interface B and class Almp.
Although the use of the separate option for generating virtual function tables alleviates this difficulty, additional difficulties arise. Figure 3 illustrates the object layouts with separate virtual function tables. In this example, the object layout 304 for class Blmp has two virtual function tables. The first virtual function table has the order of entries to be virtual functions Al and A2, which is consistent with the ordering for class Almp. The second virtual function table has the order of entries to be virtual functions Al and Bl, which is consistent with the ordering for interface B. The difficulty arises because the developer of class Blmp, who wants to reuse the implementation of interface A, which is class Almp, must provide an implementation for each virtual function of interface A within class Blmp. (These multiple implementations can be avoided by virtually inheriting interface A. With such virtual inheritance, a C++ compiler might generate no virtual function tables with the required ordering of the virtual functions.) The developer of class Blmp can implement each virtual function of interface A in a straightforward manner. In particular, the developer can implement each virtual function to forward its invocation to the corresponding virtual function in the implementation of interface A, which is class Almp. The following is an example implementation of class Blmp:
Class Blmp : Almp, B
{ virtual void Bl(){... }; virtual void Al(){return AImp::Al()} }
The implementation of virtual fimction Al invokes the implementation of virtual function A 1 in the class Almp. Although this implementation is straightforward, problems arise when interface A is changed. For example, if a new virtual function A3 is added to interface A, then the developer of the class Blmp would need to change the class definition to include an implementation of the new virtual function A3. Although the changing of the class definition in this example may not be difficult, the changing of class definitions in systems that use complex inheritance hierarchies and many virtual functions can present difficulties. It would be desirable to have a technique which would avoid the difficulties of having to change class definitions when a new virtual function is added to an interface.
SUMMARY A method and system for implementing functions in a class that inherits an interface and that inherits an implementing class which implements the interface is provided. In one embodiment, a forwarding system adds to the class for each virtual fimction a forwarding implementation of that virtual function. The forwarding implementation forwards its invocation to the implementation of that the virtual function in the implementing class. In one embodiment, the forwarding system implements a special forwarding instruction that specifies the interface and implementing class. A developer of a class that inherits the interface and the implementing class inserts the forwarding instruction into the class definition. When the forwarding system encounters such an instruction during compilation of the class definition, the forwarding system provides an implementation of each virtual fimction of the interface that forwards its invocation to a corresponding virtual function in the implementing class. The forwarding system also forwards virtual functions of any direct or indirect base interface of the interface to the implementing class.
BRIEF DESCRIPTION OF THE DRAWINGS
Figure 1 illustrates a sample object layout for an object of the Shape class.
Figure 2 illustrates the difficulty when the virtual function tables are merged.
Figure 3 illustrates the object layouts with separate virtual function tables.
Figure 4 is a block diagram of an example implementation of the forwarding system.
Figure 5 is a block diagram illustrating a computer system for practicing the forwarding system.
Figure 6 is a flow diagram illustrating an example implementation of a routine to automatically add forwarding macros to interface definitions.
DETAILED DESCRIPTION
Embodiments of the present technology provide a method and system for automatically generating implementations of virtual fimctions of interfaces. The system generates the implementations so that each virtual function forwards its invocation to a virtual function that provides an implementation. In one embodiment, the forwarding system implements a special forwarding instruction that specifies an interface and an implementing class. A developer of a class that inherits the interface and the implementing class inserts the forwarding instruction into the class definition. When the forwarding system encounters such an instruction during compilation of the class definition, the forwarding system provides an implementation of each virtual function of the interface that forwards its invocation to a corresponding virtual function in the implementing class. The forwarding system also forwards virtual fimctions of any direct or indirect base interface of the interface to the implementing class. Alternatively, the forwarding system automatically
detects that no implementation has been provided for the interface and inserts a forwarding implementation to the implementing class.
In one embodiment, the forwarding system is implemented by adapting a compiler to recognize a special forwarding instruction and to automatically insert and implementation of the virtual functions. Alternatively, the forwarding system may be implemented using standard macros that are preprocessed by a compiler, such as a C++ compiler. The macro implementation of the forwarding system is referred to as the "macro system." The macro system defines a forwarding macro for each interface that provides an implementation of each virtual function that forwards the invocation of the virtual function to an implementation of that virtual function in a class whose name is passed as a parameter to the macro. The following illustrates the forwarding macro that is defined for class A: class A
{ virtual void A1()=0; #define $forwardATo(interface)\ virtual void Al(){return interface##::Al()}; }
The "#define" indicates that a macro is being defined, the "SforwardATo" is the name of the macro, and the "interface" is the name of a parameter that is passed when the macro is expanded. The body of the macro is "virtual void Al(){return interface##::Al()};" where "interface##" indicates that the passed parameter is to be substituted. The macro definition is terminated by a statement that does not end with a "\". In other words, a "\" at the end of a statement within the macro indicates that the macro continues onto the next line. When this macro is expanded the parameter such as "Imp," the result is: virtual void Al() {return Imp::Al()};
which forwards the invocation of virtual function Al to the implementation of virtual function Al in class Imp.
The implementation of interface B, which is class Blmp, can call the macro SforwardATo passing the name of the implementation of interface A, which is class Almp.
When the macro is expanded, an implementation of virtual function Al is provided that forwards its invocation to the implementation of class Almp. The following illustrates the use of that macro: class Blmp : Almp, B { virtual void Bl (){... }; $forwardATo(AImp)
}
The following illustrates the definition of class Blmp when the macro is expanded: class Blmp : Almp, B
{ virtual void Bl (){... }; virtual void Al(){return AImp::Al()}; }
If new virtual functions are added to interface A, the SforwardATo macro is redefined to add statements that are forwarding implementations of the new virtual functions. Because class Blmp calls that macro, when the macro is expanded, the definition of class Blmp will include forwarding implementations of the new virtual functions. Thus, once a developer adds a forwarding macro to class Blmp modifications to interface A are automatically reflected in class Blmp.
The definition of such a forwarding macro needs to include statements that will generate forwarding implementations of each virtual function in inherited interfaces.
The following illustrates the forwarding macro for interface B that inherits interface A: class B : A { virtual void Bl ()=0; #define $forwardBTo(interface)\ $forwardATo(interface)\ virtual void Bl(){return interface##::Bl()}; }
An implementing class that inherits interface B need only expand the forwarding macro for interface B, which automatically expands the forwarding macro for interface A. The
following illustrates an implementation of interface C, which is class Clmp, that uses the forwarding macro of interface B: class C : B
{ virtual void Cl ()= ;
} class Clmp : Blmp, C
{ virtual void Cl(){ .. };
$forwardBTo(BImp)
}
The following illustrates expansion of the forwarding macro in class Clmp: class Clmp : Blmp, C { virtual void Cl (){... }; virtual void Al(){return BImp::Al()}; virtual void Bl(){return BImp::Bl()};
}
A difficulty with the naming convention of these forwarding macros is that an implementation needs to know of any directly inherited interface of its directly inherited interface. For example, the implementation of interface C, which is class Clmp, needs to know that interface B is directly inherited by interface C so that the appropriate forwarding macro, "SforwardBTo," can be used. One embodiment of the macro system overcomes this difficulty by defining an additional parent class forwarding macro for each interface that inherits an interface. The parent class forwarding macro has a name that is based solely on the interface for which it is defined, but calls the forwarding macro for its directly inherited interfaces. The following definition of interface B illustrates the parent class forwarding macro: class B : A
{ virtual void Bl ()=0;
#define $forwardBTo(interface)\
$forwardATo(interface)\ virtual void Bl(){return interface##::Bl()};
#define $forwardBParentClassTo(interface)\
$forwardATo(interface) }
The parent class forwarding macro is "SforwardBParentClassTo." This macro calls the forwarding macro for its inherited interface A. An implementing class can call the parent class forwarding macro of its directly inherited interface rather than calling the forwarding macro of an indirectly inherited interface. Thus, the implementation need not be aware that an inherited interface happens to inherit another interface. The following illustrates the use of the parent class forwarding macro: class Blmp : Almp, B { virtual void Bl(){. . }; $forwardBParentClassTo(AImp)
}
The expansion of the parent class forwarding macro is illustrated in the following: class Blmp : Almp, B
{ virtual void Bl(){... }; virtual void Al(){return AImp::Al()}; }
More generally, any interface regardless of whether it currently inherits another interface can provide an implementation of the parent class forwarding macro. If the interface does not currently inherit another interface, then the parent class forwarding macro would be defined to be empty. Thus, when such a parent class forwarding macro is expanded, no statements are inserted into the calling class definition and the expansion would have no effect. If, however, the interface is eventually changed to inherit another interface, then the parent class forwarding macro would be redefined to call the forwarding macro of the inherited interface. The change in the parent class forwarding macro would automatically the reflected when the parent class forwarding macro is expanded in the calling class definition.
Figure 4 is a block diagram of an example implementation of the forwarding system. In this implementation, the forwarding system may be implemented as part of a
compiler or as a preprocessor to a compiler. The process forwarding instruction routine is invoked when the forwarding system encounters a special forwarding instruction, which specifies an interface and an implementing class or automatically detects such a situation. The routine inserts, into the class definition that inherits the interface and that inherits the implementing class, a forwarding implementation for each virtual function of the interface. The routine then recursively calls itself to insert forwarding implementations for virtual functions of any indirectly inherited interfaces of the interface. In steps 401-403, the routine loops inserting forwarding implementations for each virtual function of the interface. In step 401, the routine selects the next virtual function of the interface. In step 402, if all the virtual functions have aheady been selected, then the routine continues at step 404, else the routine continues at step 403. In step 403, the routine inserts a forwarding implementation of the selected virtual function that forwards its invocation to the implementing class. In step 404, if the interface has an inherited interface (i.e., a base interface), then the routine continues at step 405, else the routine returns. In step 405, the routine recursively invokes the process forwarding instruction routine passing the base interface and the implementing class. The routine then returns.
Figure 5 is a block diagram illustrating a computer system for practicing the forwarding system. The computer system 500 includes a central processing unit 501, I/O devices 502, and memory 503. The I/O devices may include computer readable media, such as a hard disk or a flexible disk, on which components of the forwarding system may be stored. The forwarding system that is stored in memory is the macro system. The forwarding system comprises an add forwarding macro component 505. The add forwarding macro component inputs interface definitions 504 and outputs modified interface definitions 506. The add forwarding macro component inserts the forwarding macro and the parent class forwarding macro into the interface definitions. The compiler preprocessor 508 inputs the modified interface definitions 506 and class definitions that have calls to the macros 507. The compiler preprocessor expands the macros within the class definitions to generate expanded class definitions 509. The compiler 510 inputs the expanded class definitions to generate the compiled code.
Figure 6 is a flow diagram illustrating an example implementation of a routine to automatically add forwarding macros and parent class forwarding macros to interface definitions. This routine is passed an interface definition and inserts macro definitions for the forwarding macro and the parent class forwarding macro. In step 601, the routine inserts a statement "#define $forward<class>To(interface)\" into the interface definition. This statement starts the definition of the forwarding macro. The "<class>" is replaced by the name of the interface. In step 602, if the interface inherits a base interface, then the routine continues that step 603, else the routine continues that step 604. In step 603, the routine inserts the statement "$forward<baseclass>To(interface);\". The "<baseclass>" is replaced by the name of the inherited interface. This statement calls the forwarding macro of the inherited interface. In steps 604-606, the routine loops adding forwarding implementations for each virtual function of the interface. In step 604, the routine selects the next virtual function. In step 605, if all the virtual functions have aheady been selected, then the routine continues at step 607, else the routine continues at step 606. In step 606, the routine adds the forwarding implementation of the selected virtual function and loops to step 606 to select the next virtual function. In step 607, the routine adds a termination for the macro definition. The termination may be accomplished by inserting a blank line. In the step 608, the routine adds the statement "#define $forward<class>ParentClassTo(interface)\". This statement defines the parent class forwarding macro. In step 609, if the interface inherits a base interface, then the routine continues its step 610, else the routine continues that step 611. In step 610, the routine adds the statement "$forward<baseclass>To(interface)\". This statement calls the forwarding macro of the base interface. If, however, the interface inherits no base interface, then the parent class forwarding macro is empty. In step 611, the routine adds a termination of the macro definition and completes.
From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
Claims
1. A method in a computer system for implementing virtual functions in a class that inherits an interface and that inherits an implementing class that implements the interface, the method comprising for each virtual function of the interface, adding to the class a forwarding implementation of that virtual function that forwards its invocation to the implementation of that virtual fimction in the implementing class.
2. The method of claim 1 including for a base interface of the interface, adding to the class a forwarding implementation of each virtual function of the base interface that forwards its invocation to the implementation of that virtual function in the implementing class.
3. The method of claim 1 wherein the adding is performed by a preprocessor of a compiler.
4. The method of claim 1 wherein the adding is performed by a compiler.
5. The method of claim 1 wherein the adding is performed by a macro processor.
6. The method of claim 1 wherein the class includes a call to a forwarding macro defined for a base interface of the interface.
7. The method of claim 1 wherein the class includes a call to a parent class forwarding macro defined for the interface.
8. A method for defining a macro for an interface, the method comprising specifying a forwarding macro that is passed a name of an implementing class an that includes an implementation of each virtual function of the interface that forwards its invocation to a corresponding virtual function in the named implementing class.
9. The method of claim 8 wherein the forwarding macro includes a call to a forwarding macro defined for a base interface of the interface.
10. The method of claim 8 including specifying a parent class forwarding macro that is passed the name of the implementation and that includes a call to a forwarding macro of a base interface.
11. A method for implementing virtual functions in a class that inherits an interface and that inherits an implementing class that implements the interface, the method comprising adding a call to a macro defined for the interface passing a name of the implementing class so that a forwarding implementation for each virtual function of the interface forwards its invocation to the implementation of that virtual function in the implementing class.
12. The method of claim 11 wherein the macro is a forwarding macro.
13. The method of claim 11 wherein the macro is a parent class forwarding macro.
Applications Claiming Priority (21)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US322457 | 1994-10-11 | ||
US322643 | 1994-10-13 | ||
US11866899P | 1999-02-03 | 1999-02-03 | |
US118668P | 1999-02-03 | ||
US09/322,643 US7039943B1 (en) | 1999-02-03 | 1999-05-28 | Audio visual architecture |
US09/322,459 US6466234B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for controlling environmental conditions |
US322962 | 1999-05-28 | ||
US322207 | 1999-05-28 | ||
US09/322,962 US6684246B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for tracking clients |
US322455 | 1999-05-28 | ||
US322965 | 1999-05-28 | ||
US322852 | 1999-05-28 | ||
US09/322,852 US6993771B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for managing software components |
US322459 | 1999-05-28 | ||
US09/322,457 US6970925B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for property notification |
US09/322,455 US6721898B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for tracking software components |
US09/322,207 US6670934B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for distributing art |
US09/322,965 US6704924B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for implementing virtual functions of an interface |
US322964 | 1999-05-28 | ||
US09/322,964 US7617453B1 (en) | 1999-02-03 | 1999-05-28 | Method and system for generating a user interface for distributing devices |
PCT/US2000/002909 WO2000046670A1 (en) | 1999-02-03 | 2000-02-03 | Method and system for implementing virtual functions of an interface |
Publications (1)
Publication Number | Publication Date |
---|---|
EP1157330A1 true EP1157330A1 (en) | 2001-11-28 |
Family
ID=27581023
Family Applications (9)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00919268A Expired - Lifetime EP1159680B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for property notification |
EP00911717A Withdrawn EP1171815A2 (en) | 1999-02-03 | 2000-02-03 | Method and system for distributing art |
EP00913379A Withdrawn EP1157334A1 (en) | 1999-02-03 | 2000-02-03 | Method and system for managing software components |
EP00914539A Expired - Lifetime EP1159676B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for controlling lighting |
EP00913381.0A Expired - Lifetime EP1159669B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for generating a user interface for distributed devices |
EP00911713A Expired - Lifetime EP1155534B1 (en) | 1999-02-03 | 2000-02-03 | Audio visual architecture |
EP00911714A Expired - Lifetime EP1157333B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for tracking software components |
EP00910074A Withdrawn EP1157330A1 (en) | 1999-02-03 | 2000-02-03 | Method and system for implementing virtual functions of an interface |
EP00907167A Expired - Lifetime EP1171819B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for tracking clients |
Family Applications Before (7)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00919268A Expired - Lifetime EP1159680B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for property notification |
EP00911717A Withdrawn EP1171815A2 (en) | 1999-02-03 | 2000-02-03 | Method and system for distributing art |
EP00913379A Withdrawn EP1157334A1 (en) | 1999-02-03 | 2000-02-03 | Method and system for managing software components |
EP00914539A Expired - Lifetime EP1159676B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for controlling lighting |
EP00913381.0A Expired - Lifetime EP1159669B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for generating a user interface for distributed devices |
EP00911713A Expired - Lifetime EP1155534B1 (en) | 1999-02-03 | 2000-02-03 | Audio visual architecture |
EP00911714A Expired - Lifetime EP1157333B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for tracking software components |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP00907167A Expired - Lifetime EP1171819B1 (en) | 1999-02-03 | 2000-02-03 | Method and system for tracking clients |
Country Status (6)
Country | Link |
---|---|
EP (9) | EP1159680B1 (en) |
AT (5) | ATE368253T1 (en) |
AU (9) | AU2870800A (en) |
CA (9) | CA2396118A1 (en) |
DE (5) | DE60034218T2 (en) |
WO (9) | WO2000046676A2 (en) |
Families Citing this family (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1717666A1 (en) * | 2002-03-08 | 2006-11-02 | Revelations in Design, LP | Electric device control apparatus |
EP1483653B1 (en) | 2002-03-08 | 2006-05-31 | Revelations in Design, LP | Electric device control apparatus |
TWM327001U (en) * | 2006-12-28 | 2008-02-11 | Pin Life Co Ltd | Apparatus of creating atmosphere |
US8190301B2 (en) | 2008-02-19 | 2012-05-29 | Genea Energy Partners, Inc. | Building optimization system and lighting switch with adaptive blind, window and air quality controls |
CN101641998A (en) * | 2007-02-16 | 2010-02-03 | 基因能源伙伴公司 | Building optimization system and lighting switch |
ATE541436T1 (en) | 2007-05-09 | 2012-01-15 | Koninkl Philips Electronics Nv | METHOD AND SYSTEM FOR CONTROLLING A LIGHTING SYSTEM |
DE102012204686B3 (en) * | 2012-03-23 | 2013-05-23 | Siemens Aktiengesellschaft | Method for configuring lighting system in e.g. office building, involves producing live image of room by electronic camera, and performing identification based on live image that is modified by modification operation |
CN106133681A (en) * | 2014-03-21 | 2016-11-16 | 诺基亚技术有限公司 | Use standardized user interface descriptor to piece the method and apparatus that user interface controls smart object together |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19535519A1 (en) * | 1995-09-25 | 1997-03-27 | Ibm | Reducing range of compiled object-oriented programs for class library |
Family Cites Families (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5086385A (en) * | 1989-01-31 | 1992-02-04 | Custom Command Systems | Expandable home automation system |
US5390328A (en) * | 1992-03-30 | 1995-02-14 | International Business Machines Corporation | Data processing system and method for providing notification in a central processor of state changes for shared data structure on external storage |
WO1994011810A1 (en) * | 1992-11-13 | 1994-05-26 | Microsoft Corporation | A method and system for marshalling interface pointers for remote procedure calls |
US5410326A (en) * | 1992-12-04 | 1995-04-25 | Goldstein; Steven W. | Programmable remote control device for interacting with a plurality of remotely controlled devices |
US5315703A (en) * | 1992-12-23 | 1994-05-24 | Taligent, Inc. | Object-oriented notification framework system |
US5621662A (en) * | 1994-02-15 | 1997-04-15 | Intellinet, Inc. | Home automation system |
US5522077A (en) * | 1994-05-19 | 1996-05-28 | Ontos, Inc. | Object oriented network system for allocating ranges of globally unique object identifiers from a server process to client processes which release unused identifiers |
JPH10504919A (en) * | 1994-06-30 | 1998-05-12 | インテル コーポレイシヨン | Data prefetching for script-based multimedia systems |
US5802291A (en) * | 1995-03-30 | 1998-09-01 | Sun Microsystems, Inc. | System and method to control and administer distributed object servers using first class distributed objects |
US5726979A (en) * | 1996-02-22 | 1998-03-10 | Mci Corporation | Network management system |
JP3735942B2 (en) * | 1996-06-04 | 2006-01-18 | ソニー株式会社 | COMMUNICATION CONTROL METHOD, COMMUNICATION SYSTEM AND ELECTRONIC DEVICE USED FOR THE SAME |
US5727145A (en) * | 1996-06-26 | 1998-03-10 | Sun Microsystems, Inc. | Mechanism for locating objects in a secure fashion |
EP0854607A1 (en) * | 1997-01-20 | 1998-07-22 | Siemens Schweiz AG | Method for planning and configuring a communications network |
WO1998049618A1 (en) * | 1997-04-30 | 1998-11-05 | The Foxboro Company | Methods and systems for synchronizing processes executing on a digital data processing system |
US6535878B1 (en) * | 1997-05-02 | 2003-03-18 | Roxio, Inc. | Method and system for providing on-line interactivity over a server-client network |
EP1015962B2 (en) * | 1997-06-25 | 2006-11-02 | Samsung Electronics Co., Ltd. | Method for creating home network macros |
EP0889636B1 (en) * | 1997-06-30 | 2005-08-24 | Fuji Photo Film Co., Ltd. | Image communication system and method |
-
2000
- 2000-02-03 CA CA002396118A patent/CA2396118A1/en not_active Abandoned
- 2000-02-03 WO PCT/US2000/003101 patent/WO2000046676A2/en active IP Right Grant
- 2000-02-03 AU AU28708/00A patent/AU2870800A/en not_active Abandoned
- 2000-02-03 AT AT00907167T patent/ATE368253T1/en not_active IP Right Cessation
- 2000-02-03 CA CA002396109A patent/CA2396109A1/en not_active Abandoned
- 2000-02-03 EP EP00919268A patent/EP1159680B1/en not_active Expired - Lifetime
- 2000-02-03 CA CA002398342A patent/CA2398342A1/en not_active Abandoned
- 2000-02-03 EP EP00911717A patent/EP1171815A2/en not_active Withdrawn
- 2000-02-03 WO PCT/US2000/003090 patent/WO2000046675A1/en active Application Filing
- 2000-02-03 AU AU34840/00A patent/AU3484000A/en not_active Abandoned
- 2000-02-03 WO PCT/US2000/003088 patent/WO2000046960A1/en active IP Right Grant
- 2000-02-03 EP EP00913379A patent/EP1157334A1/en not_active Withdrawn
- 2000-02-03 CA CA002396124A patent/CA2396124A1/en not_active Abandoned
- 2000-02-03 WO PCT/US2000/003089 patent/WO2000046674A1/en active Application Filing
- 2000-02-03 CA CA002396104A patent/CA2396104A1/en not_active Abandoned
- 2000-02-03 DE DE60034218T patent/DE60034218T2/en not_active Expired - Lifetime
- 2000-02-03 WO PCT/US2000/003097 patent/WO2000046671A1/en active IP Right Grant
- 2000-02-03 AU AU32225/00A patent/AU3222500A/en not_active Abandoned
- 2000-02-03 WO PCT/US2000/002953 patent/WO2000046673A1/en active IP Right Grant
- 2000-02-03 EP EP00914539A patent/EP1159676B1/en not_active Expired - Lifetime
- 2000-02-03 AU AU33571/00A patent/AU3357100A/en not_active Abandoned
- 2000-02-03 AU AU35914/00A patent/AU3591400A/en not_active Abandoned
- 2000-02-03 AT AT00911713T patent/ATE384371T1/en not_active IP Right Cessation
- 2000-02-03 EP EP00913381.0A patent/EP1159669B1/en not_active Expired - Lifetime
- 2000-02-03 AU AU33573/00A patent/AU3357300A/en not_active Abandoned
- 2000-02-03 CA CA002396131A patent/CA2396131A1/en not_active Abandoned
- 2000-02-03 AU AU34842/00A patent/AU3484200A/en not_active Abandoned
- 2000-02-03 WO PCT/US2000/003096 patent/WO2000046660A2/en active Application Filing
- 2000-02-03 AT AT00919268T patent/ATE358846T1/en not_active IP Right Cessation
- 2000-02-03 EP EP00911713A patent/EP1155534B1/en not_active Expired - Lifetime
- 2000-02-03 AT AT00911714T patent/ATE406612T1/en not_active IP Right Cessation
- 2000-02-03 EP EP00911714A patent/EP1157333B1/en not_active Expired - Lifetime
- 2000-02-03 WO PCT/US2000/002909 patent/WO2000046670A1/en active Application Filing
- 2000-02-03 CA CA002396128A patent/CA2396128A1/en not_active Abandoned
- 2000-02-03 CA CA002396099A patent/CA2396099A1/en not_active Abandoned
- 2000-02-03 EP EP00910074A patent/EP1157330A1/en not_active Withdrawn
- 2000-02-03 DE DE60017369T patent/DE60017369T2/en not_active Expired - Lifetime
- 2000-02-03 CA CA2396094A patent/CA2396094C/en not_active Expired - Fee Related
- 2000-02-03 AU AU39981/00A patent/AU3998100A/en not_active Abandoned
- 2000-02-03 DE DE60037795T patent/DE60037795T2/en not_active Expired - Lifetime
- 2000-02-03 AT AT00914539T patent/ATE287104T1/en not_active IP Right Cessation
- 2000-02-03 DE DE60035677T patent/DE60035677T2/en not_active Expired - Lifetime
- 2000-02-03 EP EP00907167A patent/EP1171819B1/en not_active Expired - Lifetime
- 2000-02-03 WO PCT/US2000/003098 patent/WO2000046657A2/en active Application Filing
- 2000-02-03 AU AU33570/00A patent/AU3357000A/en not_active Abandoned
- 2000-02-03 DE DE60040061T patent/DE60040061D1/en not_active Expired - Lifetime
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE19535519A1 (en) * | 1995-09-25 | 1997-03-27 | Ibm | Reducing range of compiled object-oriented programs for class library |
Also Published As
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20050125805A1 (en) | Method and system for implementing virtual functions of an interface | |
JP4684376B2 (en) | Method, computer program product, system and recording medium for interconnecting software drivers in kernel mode | |
US6345382B1 (en) | Run-time customization in object-oriented design | |
JP3929554B2 (en) | How to validate file object generation and route messages to the file object | |
Vinoski | Distributed object computing with CORBA | |
US5724589A (en) | Development system with a property-method-event programming model for developing context-free reusable software components | |
US5842220A (en) | Methods and apparatus for exposing members of an object class through class signature interfaces | |
US7886286B2 (en) | Integration of non-componentized libraries in component-based systems | |
US8032861B2 (en) | Extensible object model | |
US20040226030A1 (en) | Systems and methods for an extensible software proxy | |
US8966456B2 (en) | System and method for providing and using meta-data in a dynamically typed array-based language | |
US6139198A (en) | System and method for enabling tracing of program execution in an object-oriented system | |
KR19990071993A (en) | System platform for communication system | |
JP2007012066A (en) | Introspection support for local and anonymous class | |
US8271622B2 (en) | Method and apparatus for a system management tool to adapt command interface and behavior based on installed features | |
JP2006302285A (en) | Embodiment of generic types maintaining migration compatibility | |
JP2007012064A (en) | Allowing non-generified method to override generified method | |
CN100478879C (en) | Method for service logic mapping onto applied language discribed by XML language | |
EP1157330A1 (en) | Method and system for implementing virtual functions of an interface | |
US6788317B2 (en) | Generation of delegating implementation for IDL interfaces which use inheritance | |
Neumann et al. | Filters as a Language Support for Design Patterns in Object-Oriented Scripting Languages. | |
US5970250A (en) | System, method, and computer program product for scoping operating system semanticis in a computing environment supporting multi-enclave processes | |
US20050021305A1 (en) | Various methods and apparatuses for interfacing of a protocol monitor to protocol checkers and functional checkers | |
US20060080644A1 (en) | Parameterization of programming structures | |
US7802239B2 (en) | Supporting method references in the JAVA language |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
17P | Request for examination filed |
Effective date: 20010903 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE |
|
AX | Request for extension of the european patent |
Free format text: AL;LT;LV;MK;RO;SI |
|
17Q | First examination report despatched |
Effective date: 20030318 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN |
|
18D | Application deemed to be withdrawn |
Effective date: 20100901 |