NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18506

Text File | 1992-12-29 | 4.4 KB | 88 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!news.mentorg.com!scherzo!bcohen
From: [e-mail] (Bruce Cohen)
Subject: Re: .. ptr_cast ..
Sender: [e-mail] (News User)
Message-ID: <[e-mail]>
Date: Tue, 29 Dec 1992 19:14:33 GMT
References: <[e-mail]> <rmartin.725047369@thor>
Nntp-Posting-Host: scherzo.mentorg.com
Organization: Mentor Graphics Corporation
Keywords: ptr_cast
Followup-To:
Lines: 73

In article <rmartin.725047369@thor>, [e-mail] (Bob Martin) writes:
|> ...
|> In general, to be able to answer this question, you must have some
|> kind of ID which is unique for every different class.  Then a virtual
|> function which all objects posess which asks the question.  When the
|> function executes, it checks the ID of the object with the ID in the
|> query.  If they match, it returns TRUE, otherwise it returns the
|> result gotten by calling the same function in each of the base
|> classes.  At the top of the inheritance hierarchy there is a class
|> which all other classes must derive from.  Call it "Object".  This
|> class declares the virtual query function and creates an
|> implementation which returns FALSE.
|>
|> You can work out the rest of the details for yourself, it is not real
|> hard.
|>
|> However, it should be noted that implementing such schemes places a
|> burden upon your class hierarchy.  Every class must have the ID, every
|> class must implement your query function, etc, etc.  Third party
|> classes cannot directly participate, someone must be in charge of
|> dispensing unique ID codes to prevent the possibility of overlap, etc,
|> etc...

There is an alternative which reduces the overhead so that only classes
which actively need RTTI need to support it: make an RTTI mix-in class
and have any class that needs RTTI inherit it.  The simplest way I know
of to implement this is with templates, which takes care of generating
the unique ID's and allows third-party classes to be added.  I'd include
some source to demonstrate, but I implemented this scheme at a former
job, and didn't get to take the source code along when I left.  I do
have a short paper describing the general scheme lying around here somewhere;
it was published in the proceedings of the Workshop on Reflection at
OOPSLA '91.

The scheme I implemented did more than just provide type ID; it was
really a primitive Meta Object Protocol (MOP) which allowed adding
functionality like printing an object or saving an object description to
a file without having to code the capability into the object's class,
even adding it after the class was completely coded.  So you can do
some fairly powerful things with the type system without any compiler support.
But there are drawbacks: additional overhead and requiring recompilation of a
class (actually its template instance) to add the RTTI mix-in.  And some
of the functionality I'd like to have in a Meta Object Protocol really
requires more help from the compiler than you can get from templates.

|>
|> If you get the idea that I don't like to see schemes like this, you
|> are right.  If at all possible, I would wait for the compiler vendors
|> to implement the RTTI proposal.

I agree with this.  The implementation I did was purely a
proof-of-concept, to show that a problem we had could be solved that
way.  I would have been overjoyed to not have to have done it myself, as
implementing it was quite tedious.

|>
|> Once you have RTTI, the temptation is to use it all the time.  Taken
|> to its extreme, this will cause you to undo many of the benefits of
|> OO. You should be very jealous of the secrecy of the type of an
|> object.  It should be exposed only in the most extraordinary of
|> circumstances.  There are certainly cases where RTTI is useful, but is
|> is also very easy to abuse.
|>

Also true.  I see RTTI and MOP techniques as tools for system-level
programmers to implement additional general capabilities for objects
such as persistence, debug support, instance cloning, remote
instantiation, etc., etc.  Most times it should not be visible as RTTI
to the application programmer even when it's being used.
------------------------------------------------------------------------
Bruce Cohen, Mentor Graphics Corpooration | email: [e-mail]
8005 SW Boeckman Road                     | phone: [phone]
Wilsonville, OR 97070-7777                |