Hello Jerry!
 JC> Hi Ron, it's been a while...
True.  But I still lurk...
 RB> IIRC, the draft standard specifies that RTTI is only available for
 RB> classes that have at least one virtual function.  If so, it's fairly
 RB> clear that the compiler only has to go to the memory 
 JC> pointed to by the
 RB> original void pointer, look at the "standard" offset 
 JC> in the (presumed)
 RB> object for the vtable pointer, and then determine if the data at that
 RB> offset is a pointer that points to a true vtable.
 JC> The problem is that if the pointer isn't to the right kind of class at
 JC> all in the first place.  If the compiler attempts to dereference it,
 JC> that could produce all sorts of problems all by itself.
I assume that you are refering to the fact that not all addresses are valid?  
Seems to me that if dereferencing what "ought" to be the vtable pointer 
causes a processor exception, dynamic_cast should be able to catch the 
exception and return a NULL pointer.  Implementation details are left to the 
compiler/library writer.
 JC> Worse, how can it determine whether or not what's pointed at is a true
 JC> vtable or not?  If it's not, the code has to give a NULL pointer.
The model that I have in my mind is that the vtable is really a static data 
member of the class, initialized either before main()/WinMain() is entered, 
or possibly the first time a constructor is called for an object of the 
class, or for an object of a class derived from the class.  Consequently, its 
address (the value of the vtable pointer) can be used by the compiler in just 
the same way as the address of any static data item.
IIRC, the model suggested by Soustrup(sp?) in "Design and Evolution" is that 
a derived class's vtable would include a pointer to its parent's vtable 
(let's not get into the MI can of worms here) at a fixed offset, so all that 
dynamic_cast has to do is to track through the linked list to see if it can 
get from the object to a vtable pointer that is equal to the value for the 
class that the cast is for.  Again, if it comes to a NULL (indicating the 
base class for which virtual functions were declared) or dereferencing one of 
the pointers causes a processor exception, dynamic_cast just returns a NULL.
 JC> However, anything it has in memory that it uses to identify a vtable, I
 JC> can (accidentally or otherwise) have in memory otherwise as well, and my
 JC> pointer will be mis-identified as a pointer to a class, even though it's
 JC> not.
I'm not sure the systen tries that hard to be completely certain.  My gut 
reaction that this is a source of potential run-time bugs waiting to bite...
I'll have to take a snoop through the Microsoft RTL, to see if there is any 
indication of how they implement this sort of thing.
 JC> The only way I can see to be absolutely certain about this is to always
 JC> keep a table of all objects that have been created, and search for the
 JC> passed pointer in that table.  Offhand, this sounds slow and memory
 JC> hungry at best...
I agree!
ttfn
     -Ron  (rbass@intersecttech.com)
--- EZPoint V2.2
---------------