Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!ucbvax!janus.Berkeley.EDU!haskell From: haskell@janus.Berkeley.EDU (Paul Haskell) Newsgroups: comp.lang.c++ Subject: QUESTION: calling appropriate copy constructor Message-ID: <38098@ucbvax.BERKELEY.EDU> Date: 12 Aug 90 07:51:31 GMT Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: haskell@janus.Berkeley.EDU (Paul Haskell) Distribution: usa Organization: University of California, Berkeley Lines: 46 Does anyone have useful insight on the following question? Here is our (simplified) situation... 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. We would like to be able to make copies of the list's members. To make a copy, currently we find the list entry we wish to duplicate with something like: int j = 0; while((j < list_length)&&(win_id_to_match != list_elems[j].win_id)) { j++; } if (win_id_to_match == list_elems[j].win_id) { ... ... } (So, our method of deciding which list element to copy has nothing to do with the actual type of the list element.) Presumably for "... ..." we have to call either "new_pointer = new bitmap(list_elems[j])", "new_pointer = new graphics(list_elems[j])", or "new_pointer = new text(list_elems[j])" depending on the derived type of "list_elems[j]". 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() ? The problem with this method is that when new derived classes are designed, the designer has to remember to add the virtual return_type() function with a unique return-value AND to modify the switch() to contain another "new derived_class(list_elems[j])" statement. Thanks very much for any suggestions. Paul