Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!brutus.cs.uiuc.edu!samsung!uunet!mcsun!sunic!tut!tukki!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: Is there a way to tell which derived class an object belongs to?
Message-ID: <2903@tukki.jyu.fi>
Date: 1 Feb 90 08:31:59 GMT
References: <2815@draken.nada.kth.se> <636@tci.bell-atl.com> <7722@chaph.usc.edu>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
          SAKKINEN@FINJYU.bitnet (alternative)
Organization: University of Jyvaskyla, Finland
Lines: 30

In article <7722@chaph.usc.edu> jeenglis@nunki.usc.edu (Joe English) writes:
>kempf@tci.bell-atl.com (Cory Kempf) writes:
>>matsl@nada.kth.se (Mats Luthman) writes:
> ...
>An earlier poster (Mats Luthman, matsl@nada.kth.se)
>came up with a nice way to do it, though:
>have a tag() function in each derived class 
>returning the address of a private static variable;
>the linker will generate unique ID's then
>no matter how many new types are introduced.

Since Luthman's scheme as such uses only the _address_ of that private
static variable, here we have a case where a variable of type _void_
would be optimal! Of course, the variable could well be of string type
and contain the name of the class.

A drawback of Luthman's scheme is that the programmer must remember
to really redefine the class-identifying function in every subclass
(derived class); otherwise the objects will seem to belong to the
superclass (base class) at least in the case of single inheritance.
With multiple immediate base classes, I suppose the compiler will
give an error message about ambiguous definitions if the programmer
forgets the redefinition.

Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finland