Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pacbell!hoptoad!hsfmsh!dumbcat!marc
From: marc@dumbcat.UUCP (Marco S Hyman)
Newsgroups: comp.lang.c++
Subject: Re: Re^2: Is there a way to tell which derived class an object belongs to?
Summary: Murphy's Law will win in manual system
Message-ID: <133@dumbcat.UUCP>
Date: 3 Feb 90 23:06:13 GMT
References: <2815@draken.nada.kth.se> <636@tci.bell-atl.com> <7722@chaph.usc.edu> <645@tci.bell-atl.com>
Organization: MH Software, Hayward, Ca.
Lines: 44

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