If you have to call the static member function through a normal member function, it is pointless to make it static. Can you think of a reason why you would need virtual static member functions?
Edited by - null_pointer on February 3, 2001 5:28:37 PM
virtual static members.
There are practical uses for virtual static methods. Two examples that come to mind are related to resource management and file importing.
Say you designed a resource manager that bound files to runtime objects based on file extension. Classes for these objects could supply the applicable file extension(s) matching those objects. These would be static methods of the class, since the information represents information about the class as a whole, not individual object instances. However, they would also need to be virtual, since each subclass from the base resource object chooses its own extension(s) to support, and these choices can be made at runtime, not necessarily compile time.
A second example (although somewhat related to the first) would be a file importer. Say you have a collection of importer objects that support some kind of import class interface to convert one form of data into another, with the available importers determined at runtime (via plug-ins or whatnot). Since you would not want to have to instantiate an importer object just to see what import capabilities it has (i.e. what kind of data it imports and exports etc), it would be very handy to have this information available via the importer subclass itself, hence a static method. But once again, this method must be virtual, since importer subclasses are determined at runtime.
These are just a couple examples, and I''ve actually encountered plenty more in practice that make virtual static a very useful construct. Unfortunately C++ doesn''t support such a thing.
The solution I''ve adopted is simply to use a "class object" sort of pattern, where the "virtual static" methods are just normal virtual methods of the class object rather than the objects themselves, so I can query these class objects for overall class information rather than be forced to create instances for this purpose. By adding functionality to subclasses of the base "class object" via virtual functions, you get the behavior of virtual static functions even though C++ doesn''t allow them directly.
You can find an implementation of this in the Reflective Factory pattern, which I''ve posted up in gamedev.net''s patterns database.
Say you designed a resource manager that bound files to runtime objects based on file extension. Classes for these objects could supply the applicable file extension(s) matching those objects. These would be static methods of the class, since the information represents information about the class as a whole, not individual object instances. However, they would also need to be virtual, since each subclass from the base resource object chooses its own extension(s) to support, and these choices can be made at runtime, not necessarily compile time.
A second example (although somewhat related to the first) would be a file importer. Say you have a collection of importer objects that support some kind of import class interface to convert one form of data into another, with the available importers determined at runtime (via plug-ins or whatnot). Since you would not want to have to instantiate an importer object just to see what import capabilities it has (i.e. what kind of data it imports and exports etc), it would be very handy to have this information available via the importer subclass itself, hence a static method. But once again, this method must be virtual, since importer subclasses are determined at runtime.
These are just a couple examples, and I''ve actually encountered plenty more in practice that make virtual static a very useful construct. Unfortunately C++ doesn''t support such a thing.
The solution I''ve adopted is simply to use a "class object" sort of pattern, where the "virtual static" methods are just normal virtual methods of the class object rather than the objects themselves, so I can query these class objects for overall class information rather than be forced to create instances for this purpose. By adding functionality to subclasses of the base "class object" via virtual functions, you get the behavior of virtual static functions even though C++ doesn''t allow them directly.
You can find an implementation of this in the Reflective Factory pattern, which I''ve posted up in gamedev.net''s patterns database.
quote:Original post by Chris Hargrove
A second example (although somewhat related to the first) would be a file importer. Say you have a collection of importer objects that support some kind of import class interface to convert one form of data into another, with the available importers determined at runtime (via plug-ins or whatnot). Since you would not want to have to instantiate an importer object just to see what import capabilities it has (i.e. what kind of data it imports and exports etc), it would be very handy to have this information available via the importer subclass itself, hence a static method. But once again, this method must be virtual, since importer subclasses are determined at runtime.
I am not sure about this one, the whole point of inheritance and polymorphism is to not care about the type of data it imports exports. It should all be transparent.
Bad design cripples code.
static implies that you don''t need an object. virtual implies that you don''t need a type. If you can''t know either, how would you access a virtual static member function? You MUST provide either the type or some data that can be used to find the type.
The easiest method is to merely extend the factory concept with a map of keys to a pair of per-class allocator and per-class data pointers. I just finished writing a factory class takes four template parameters, works with any polymorphic resource (not just C++ objects), stores per-class (as in static) data, allocates objects from a user-defined type value (i.e., a string containing a file extension), deallocates objects, and checks them for validity. Did I mention that it is only 30 lines (with readable spacing) and no macros?
It relies on other parts of my template library, but if you want to see it, I''ll post it.
static implies that you don''t need an object. virtual implies that you don''t need a type. If you can''t know either, how would you access a virtual static member function? You MUST provide either the type or some data that can be used to find the type.
The easiest method is to merely extend the factory concept with a map of keys to a pair of per-class allocator and per-class data pointers. I just finished writing a factory class takes four template parameters, works with any polymorphic resource (not just C++ objects), stores per-class (as in static) data, allocates objects from a user-defined type value (i.e., a string containing a file extension), deallocates objects, and checks them for validity. Did I mention that it is only 30 lines (with readable spacing) and no macros?
It relies on other parts of my template library, but if you want to see it, I''ll post it.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
