Re: C++ rtti hack

On May 11, 9:33 pm, John Moeller <fishc...@gmail.com> wrote:


Thank you for your reply. Can you elaborate more on "it's up to the
implementation how virtual functions are resolved. It could change
underneath you."?

I would expect that any change to the compiler that would alter the
way that classes are laid out in memory would be accompanied by a
recompile of the code that is using my hack. So I am not sure if it's
relevent that a compiler could change its internal class layout;
obviously all code would need to be recompiled, not just code using
rtti, in this case. Or maybe I am misunderstanding what you mean?

And, when you say that it's up to the implementation how virtual
functions are resolved ... indeed it is, but I'm talking about rtti
here, not virtual functions. Did you mean to say that it's up to the
implementation how rtti information is stored? 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? 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?

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");
}

See, regardless of if you have a pointer to an object or a pointer to
its base object, the compiler has to be able to find the correct rtti
structure. Since the compiler can't know when it is looking up the
type_info for a B, whether or not it's really looking at an A, it
can't expect to have the rtti data in a different place for a B than
it would for an A. It has to look in a known location, relative to
the start of the class, and that location has to include the
information it needs to determine whether it is looking at a B or an
A.

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? 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?


Can you elaborate on this also please? I would definitely expect that
what you say is true - where a pointer to an object points to with
respect to that object's layout in memory, is compiler-dependent. But
why would a compiler do this differently for different virtual
classes? Why would a compiler use different layout for different
classes or class hierarchies?

Thank you!
Bryan

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]