kempf@tci.bell-atl.com (Cory Kempf) (02/02/90)
jeenglis@nunki.usc.edu (Joe English) writes: >kempf@tci.bell-atl.com (Cory Kempf) writes: >>matsl@nada.kth.se (Mats Luthman) writes: >>>Is there any way you can tell which derived class an object belongs to >>>if it is pointed to by a pointer to its base class? [method involving using a virtual member function returning a unique constant for each class deleted] > The >solution above gives that same problem to the >programmer, who has more information than >the compiler, but still not enough to do it >correctly. You have to make sure that each >time you derive a new class you give it a >unique new ID; this isn't practical in many >cases. I fail to see why. All it takes is to put up a piece of paper. When you want to create a new class, look at the last number on the list. Add one to it. Write the name of the class next to it. How is this not practical? (especially considering that I am doing this -- ie it is in practice). If you want to use a more advanced method, store the contents of the paper on the computer. Write a program that, when given a class name, will return the next available class ID. +C -- Cory Kempf Technology Concepts phone: (508) 443-7311 x341 uucp: {anywhere}!uunet!tci!kempf, kempf@tci.bell-atl.com DISCLAIMER: TCI is not responsible for my opinions, nor I for theirs
marc@dumbcat.UUCP (Marco S Hyman) (02/04/90)
In article <645@tci.bell-atl.com> kempf@tci.bell-atl.com (Cory Kempf) writes: jeenglis@nunki.usc.edu (Joe English) writes: >kempf@tci.bell-atl.com (Cory Kempf) writes: >>matsl@nada.kth.se (Mats Luthman) writes: >>>Is there any way you can tell which derived class an object belongs to >>>if it is pointed to by a pointer to its base class? [method involving using a virtual member function returning a unique constant for each class deleted] >The solution above gives that same problem to the programmer, who has >more information than the compiler, but still not enough to do it >correctly. You have to make sure that each time you derive a new class >you give it a unique new ID; this isn't practical in many cases. I fail to see why. All it takes is to put up a piece of paper. When you want to create a new class, look at the last number on the list. Picture a common scenario: Fifteen programmers are developing a product using C++ on standalone PCs. Data is transferred via floppy-net. On a whiteboard is a list of classes and class numbers. Joe Programmer needs to create a class but he can't see the white board. That's ok, he thinks, because he remembers that the last class number used was 37. So he uses 38 and tells himself he'll update the white board later. On his way out to lunch Joe looks at the white board and sees that 38 thru 42 have been used. So he writes down his class as 43 and goes out the door. He'll update the code when he gets back. Three months later the program is not making it thru final test. After many man-days of effort it's discovered that two classes have the same class number. Can't happen, you say. The original version of Murphy's law was something to the effect that if there is more than one way of doing something, someone someday will do it the wrong way. This is guaranteed. If you need some way of assigning a unique class identifier you'd better make sure it is automatic, preferably assigned by the compiler. You might not be the one to screw things up. But someone will. // marc -- // marc {ames,pyramid,sun}!pacbell!dumbcat!marc
sho@maxwell.physics.purdue.edu (Sho Kuwamoto) (02/05/90)
In article <133@dumbcat.UUCP> marc@dumbcat.UUCP (Marco S Hyman) writes: >In article <645@tci.bell-atl.com> kempf@tci.bell-atl.com (Cory Kempf) writes: >>>Is there any way you can tell which derived class an object belongs to >>>if it is pointed to by a pointer to its base class? [method involving using a virtual member function returning a unique constant for each class deleted] >Picture a common scenario: > [someone screws up by forgetting to write down the number on a] > [piece of paper. the number is reused. oops] What I'd like to see: 1) A sort of extensible enum. One you could add new members to in separate .h files. addEnum IDEnum {class1ID, class2ID, class3ID}; addEnum IDEnum {classXID, classYID}; I think this would be useful for many applications where a derived class adds functionality to an older class. 2) A "mandatory" virtual. Every derived class *must* redefine this type of method. This is not as useful, but there are a few instances (like this one) where each new class *must* redefine a method. As if C++ weren't a kitchen sink language to begin with... -Sho -- sho@physics.purdue.edu <<-- Now if only I could afford a C++ compiler for my mac... and Apple completely rewrote their ROMs for it... and...
vaughan@mcc.com (Paul Vaughan) (02/05/90)
The NIHL library implements a dynamic type facility that overcomes the difficulties that have been discussed here. It's free, it's good, it's debugged. All you've got to do is get it and use it. It probably does more than you want it to, but you can tear it apart if you wish. Sorry I'm not including a pointer to where it is--I can't find it at the moment. Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639 Box 200195, Austin, TX 78720 | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
shap@delrey.sgi.com (Jonathan Shapiro) (02/06/90)
In article <3062@pur-phy> sho@maxwell.physics.purdue.edu.UUCP (Sho Kuwamoto) writes: >What I'd like to see: >1) A sort of extensible enum. One you could add new members to > in separate .h files. For a change, I agree with a feature idea. I recently wanted this myself. The single inheritance notion would extend naturally to enums, and in several places would be very useful. Even multiple inheritance makes sense, assuming the compiler can verify that there are no enumeration value collisions. Jonathan Shapiro Silicon Graphics