Re: C++ rtti hack
On May 12, 2:19 pm, "Nevin :-] Liber" <n...@eviloverlord.com> wrote:
In article <1178877273.764959.52...@l77g2000hsb.googlegroups.com>,
bji-gg...@ischo.com wrote:
In this case, I agree
- it is up to the compiler implementation. But what I'm asking is,
does it even make sense for a compiler to *not* make what I am doing
work?
Yes.
Given that the compiler must locate the rtti structure for a
class with a vtable at runtime, how could the compiler lay class
instances out in memory such that the rtti information wasn't in the
same place for each class?
Typically the pointer to the vtable is a hidden data member of the first
class in the hierarchy *to declare a virtual function*. Also, there is
usually not a fixed slot within a vtable for the destructor, since
classes with virtual functions are not required to also have virtual
functions.
Thank you for your reply.
In answer to this part of your reply: I don't think that I am
depending on the virtual destructor being located in a specific place
in the vtable. I am just depending on there being a vtable. I could
have instead of just defining a virtual destructor in my Rtti class,
just defined a single virtual void() Dummy { } method. It's all the
same to me.
Putting it another way ... the compiler *must* make the following code
work correctly (assume that B inherits from A for this example):
B *pB = new B();
A *pA = (A *) pB; // Or dynamic_cast if you like C++ verbosity
if (typeid(*pA) == typeid(*pB)) {
printf("As expected, the typeids match");
}
This is true because A and B are in the same hierarchy of which at least
one function is virtual. Why do you expect this to generalize to
objects of types in different hierarchies?
Do you expect that a compiler would lay out the vtable and rtti
information for a class differently if it is from one hierarchy (of
objects with vtables) versus another? Why?
Given that, wouldn't an unrelated class C have the rtti data at the
same place as B and A did? Why would it have it at any different
place?
Given that one can have base classes with no virtual functions, where
exactly would you put it? The only place I can see would be before the
"this" pointer, and there are performance ramifications for doing so.
It's fine with me if there is a base class with no virtual functions -
because you can't call my LookupTypeInfo method on that class.
LookupTypeInfo *only* takes pointers to objects with vtables. The
base class you mention would not fit this criteria and could not be
passed to my method.
Unless the compiler decides that some hierarchies of class
definitions should have rtti in one place, and other hierarchies
should have it in a different place, but why would it ever do that?
To answer questions like this:
1) Read "Inside the C++ Object Model" by Stan Lippman
2) Realize that the material in that book is only one possible
implementation.
Look, I'm not saying that it would *impossible* for a compiler to work
in such a way as to break what I have done. For example, a compiler
could have a rule that said, "take the string length of the first
topmost base class of any given class, and add that to the base
pointer to the class. That's where the rtti information will be for
that class. All the other fields, and the vtable, of that class, will
be worked around this rtti information in some difficult but
predictable way." Now this would be an example of a compiler that
puts the rtti information at a different place within different class
hierarchies (a class whose base class is Foo would find the rtti at 3
bytes from the beginning of a class, a class whose base class is
FooBarBaz would find the rtti at 9 bytes from the beginning of the
class, etc).
But do you really expect to ever find such compilers in practice?
And, is there value in C++ leaving the door open for such compilers to
exist, rather than specifying more stringent rules on how classes have
to be laid out, including where the vtable and rtti data for a class
is?
On the contrary ... do you think it's valuable to be able to write
code that simply takes a pointer to "an object" of unknown type, and
is able to detect the type of that object? I think it is. I think
it's *much* more useful than allowing compilers to play silly games
which I highly, highly doubt any compiler writer has ever been
sadistic (or is it masochistic?) enough to implement in practice.
Thanks,
Bryan
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]