clarke@sessun.UUCP (Allan Clarke) (08/13/90)
haskell@janus.Berkeley.EDU writes > ... stuff deleted ... > > One of our applications has a base class "video_obj" and > derived classes "bitmap", "graphics", and "text". > We have a list of pointers to video_obj called "list_elems"; the actual > pointed-to objects may be of any of the derived types. > > ... stuff deleted ... > > So, here is the question: Is there a cleaner way of deciding which > constructor to call other than > 1) adding a virtual function "return_type()" to video_obj and its > derived classes that returns the actual type of the object > 2) switch()'ing on list_elems[j].return_type() ? > > > ... stuff deleted ... > We too have run across this scenario. We solved it by declaring that virtual method which you refer to which performs the "new" call. You can get compile time checking to make sure that all derived classes have overridden this method by declaring it as purely virtual (= 0). If you are working with an old version (pre 2.0) of cfront, you can get runtime checking by making video_obj::make_a_new_one trap out with an error. In general, switch statements like the one you allude to above should raise a red flag when you are considering such designs. Using them is likely an indicator that you are not taking proper advantage of the benefits of object-oriented design. Hope this helps some. ------------------------------------------------------------------------ Disclaimer: these words are my own. ------------------------------------------------------------------------ "All that is necessary for evil to abound is for good men to do nothing" - ??? Allan Clarke clarke@sessun.com Scientific and Engineering Software, Inc. ------------------------------------------------------------------------