C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  C++ rtti hack Goto page 1, 2  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Guest Posted: Fri May 11, 2007 4:36 am    Post subject: C++ rtti hack Hey all. I would like some comments on a C++ "hack" that I have employed in some work I have done (http://www.ischo.com/xrtti). I had to employ this hack to "work around a limitation of the C++ language. I realize that I am doing something "dangerous" that is not permitted by the language specification. However, I have a hard time thinking of how a compiler could make what I am doing *not work*. Here is the hack: Getting the C++ rtti type_info structure from a pointer only works for classes with vtables, or classes that the compiler knows the specific and definite type of at compile time. What I want to do is to get the rtti type_info for any class that has a vtable, if I have a void * pointer to an instance of that class. So I want a method that looks like this: const std::type_info &LookupTypeInfo(void *pObjectWithVtable); The following naive implementation did not work: const std::type_info &LookupTypeInfo(void *pObjectWithVtable) { return typeid(pObjectWithVtable); } This just returned (when compiled with g++) a type_info with name "Pv", which presumably means "pointer to void". So the compiler is just supplying a fixed type_info given that it knows that typeid is being called on a void *. So obviously I need to somehow cast pObjectWithVtable to something that the compiler will not think it knows the type of at compile time, and attempt to look up the rtti information in the pointed-to object. Eventually I hit on this: class Rtti { virtual ~Rtti() { } }; const std::type_info &LookupTypeInfo(void *pObjectWithVtable) { return typeid(* (Rtti *) pObjectWithVtable); } What I'm doing is casting pObjectWithVtable to the simplest vtable- containing class I can, dereferencing it, and calling typeid on that. And with g++, it works perfectly. The hacky part of this is, I am casting classes that are not Rtti classes, and don't have Rtti as an ancestor in the inheritence hierarchy, and then asking the C++ compiler to find the rtti information for that. So there is something inherently "wrong" about that - I'm asking the compiler to treat the object like it inherits from Rtti, when it doesn't, and expecting everything to work out anyway. The thing is, I believe that this will work just fine for any compiler that implements C++ rtti in a "sane" way - i.e., the same for every class regardless of its definition. Only if a C++ compiler somehow needed to know the specific type of a class in order to find its rtti information, meaning that different classes had it located in different places, would this technique not work. But I have a hard time thinking of why a compiler writer would go through the trouble to make multiple ways for rtti information to be stored in a class. This could be enforced by the C++ standard if it just said something like, "typeid is required to produce the correct type_info of any class instance it is passed even if the class instance has been cast incorrectly to a class type which is not in the inheritence hierarcy of the instance itself". This would in one fell swoop pretty much force compiler writers to make rtti information always appear at the same place in every class - something which I believe all compilers are probably already doing. In fact I would be surprised if there is a compiler out there that does *not* do this. First off - does anyone have any comments about my technique? Is it pure lunacy to even expect this to work on any compiler, let alone most or all compilers? Second - if anyone wants to find out if this technique works for their compiler, you can try this simple program: ------------------------------------------------------------ #include <stdio.h> #include <typeinfo> class Foo { public: virtual ~Foo() { } }; class Rtti { virtual ~Rtti() { } }; const std::type_info &LookupTypeInfo(void *pObjectWithVtable) { return typeid(* (Rtti *) pObjectWithVtable); } int main() { Foo f; const std::type_info &typeInfo = LookupTypeInfo(&f); printf("name: %s\n", typeInfo.name()); return 0; } ------------------------------------------------------------ If the above program prints "Foo" or something like it (g++ prints "3Foo", presumably encoding the length of the class name in a number at the beginning of the string), then my hack works on your compiler too, and I would love to hear about it. The only compiler I have tried so far is g++ 4.1.1. Thanks! Bryan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top John Moeller Guest Posted: Fri May 11, 2007 9:10 am    Post subject: Re: C++ rtti hack On Thu, 10 May 2007 22:36:56 CST, bji-ggcpp (AT) ischo (DOT) com wrote: Quote: ... class Rtti { virtual ~Rtti() { } }; const std::type_info &LookupTypeInfo(void *pObjectWithVtable) { return typeid(* (Rtti *) pObjectWithVtable); } What I'm doing is casting pObjectWithVtable to the simplest vtable- containing class I can, dereferencing it, and calling typeid on that. And with g++, it works perfectly. The hacky part of this is, I am casting classes that are not Rtti classes, and don't have Rtti as an ancestor in the inheritence hierarchy, and then asking the C++ compiler to find the rtti information for that. So there is something inherently "wrong" about that - I'm asking the compiler to treat the object like it inherits from Rtti, when it doesn't, and expecting everything to work out anyway. The thing is, I believe that this will work just fine for any compiler that implements C++ rtti in a "sane" way - i.e., the same for every class regardless of its definition. Only if a C++ compiler somehow needed to know the specific type of a class in order to find its rtti information, meaning that different classes had it located in different places, would this technique not work. But I have a hard time thinking of why a compiler writer would go through the trouble to make multiple ways for rtti information to be stored in a class. This could be enforced by the C++ standard if it just said something like, "typeid is required to produce the correct type_info of any class instance it is passed even if the class instance has been cast incorrectly to a class type which is not in the inheritence hierarcy of the instance itself". This would in one fell swoop pretty much force compiler writers to make rtti information always appear at the same place in every class - something which I believe all compilers are probably already doing. In fact I would be surprised if there is a compiler out there that does *not* do this. First off - does anyone have any comments about my technique? Is it pure lunacy to even expect this to work on any compiler, let alone most or all compilers? As you well know, this results in undefined behavior. You're asking for trouble any time a compiler changes, because it's up to the implementation how virtual functions are resolved. It could change underneath you. Additionally, when you start getting into more complicated inheritance patterns, especially those that involve virtual inheritance, the rules about where a pointer actually points to an object are up in the air. It's really not advisable, especially since your library is designed to be used on polymorphic classes. John Moeller -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Sat May 12, 2007 4:28 am    Post subject: Re: C++ rtti hack On May 12, 2:19 pm, "Nevin :-] Liber" <n...@eviloverlord.com> wrote: Quote: 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. Quote: 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? Quote: 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. Quote: 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! ] Back to top Guest Posted: Sat May 12, 2007 4:28 am    Post subject: Re: C++ rtti hack On May 12, 2:58 pm, Branimir Maksimovic <b...@hotmail.com> wrote: Quote: Wrong. I tried same hack years ago and it didn't worked. Particular compiler was g++ 2.95.2, and it didn't worked, because that compiler lays vtable pointer behind class data. So if you cast it to wrong base and you have some data in base class, compiler will look up in wrong place and segfault. I think that since 3.x version they changed that, and vtable pointer is now always first, so that's why your hack appears to work. Thank you for your reply Branimir! I am a little confused on your example, but if what you are describing is a base class with no vtable, but a subclass with a vtable, then I have addressed this already in other replies. One of my preconditions of using the LookupTypeInfo method is that the pointer passed in must point to a class with a vtable. So if you are passing in a pointer to the base class in your example, then yes, it will seg fault - because the base class has no vtable. Which is OK by me, because you've violated one of the preconditions of the method. Or am I misunderstanding your example? Thank you! Bryan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Sat May 12, 2007 4:29 am    Post subject: Re: C++ rtti hack On May 12, 2:58 pm, Sebastian Redl <e0226...@stud3.tuwien.ac.at> wrote: Quote: Now GCC (both 3.x and 4.x) put the vtable pointer before the base subobject, but there really is no reason why they should. A compiler might well put the base subobject first and the vtable pointer second. This means that the vtable is at an offset of sizeof(int) in Foo, but the compiler expects it at an offset of 0 in Rtti, leading to an incorrect dereferencing. I believe GCC 2.x had a very different layout in the face of RTTI that would break your example. I think I read somewhere that early GCC C++ compilers put the vptr at the end of an object. (However, this has so obvious drawbacks in the face of even simple inheritance that it was quickly changed.) Yes I am wondering how inheritence in object hierarchies with virtual methods worked at all in the scenario you describe for GCC 2.x. If I have a pointer to a B, which inherits from A, and both classes have a vtable ... then if I cast the B to an A, and pass that to some method, how can that method know that it really has a B and that its vtable is located in a different location than it would be if it really and truly were an A? Was there some kind of offset value stored at the beginning of the class that gave a "pointer" to the vtable? So that if you had a pointer to an A, and it really was a B, that offset would point to the vtable at the end of the composed object? If so, then this is basically the same thing; you still have some fixed data in a known location (an offset stored at the beginning of the object), and that data would be used to find both the vtable and the rtti information. So I think this would still work with my hack. Quote: And of course, passing a non-polymorphic base subobject to your function will fail. However, I believe you require a pointer to a polymorphic object anyway. Exactly. The argument to the method is called "pObjectWithAVtable" for a reason. Assuming the precondition that the pointer passed in point to an object with a vtable, I have yet to hear convincing evidence that my hack won't work on every compiler. But I do appreciate all of the replies! Thank you, Bryan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Branimir Maksimovic Guest Posted: Sat May 12, 2007 9:10 am    Post subject: Re: C++ rtti hack On May 12, 6:28 am, bji-gg...@ischo.com wrote: Quote: On May 12, 2:58 pm, Branimir Maksimovic <b...@hotmail.com> wrote: Wrong. I tried same hack years ago and it didn't worked. Particular compiler was g++ 2.95.2, and it didn't worked, because that compiler lays vtable pointer behind class data. So if you cast it to wrong base and you have some data in base class, compiler will look up in wrong place and segfault. I think that since 3.x version they changed that, and vtable pointer is now always first, so that's why your hack appears to work. Thank you for your reply Branimir! I am a little confused on your example, but if what you are describing is a base class with no vtable, but a subclass with a vtable, then I have addressed this already in other replies. One of my preconditions of using the LookupTypeInfo method is that the pointer passed in must point to a class with a vtable. So if you are passing in a pointer to the base class in your example, then yes, it will seg fault - because the base class has no vtable. Which is OK by me, because you've violated one of the preconditions of the method. Or am I misunderstanding your example? Yes, you misunderstood it. on g++ 2.95.2 this is enough for your hack to segfault class A{ public: virtual ~A(){} private: int i; }; class Rtti{ public: virtual ~Rtti(){} }; ...... A a; void* p = &a; Rtti* prtti= static_cast<Rtti*>(p); cout<<typeid(*prtti).name(); // crash Greetings, Branimir. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Branimir Maksimovic Guest Posted: Sat May 12, 2007 9:10 am    Post subject: Re: C++ rtti hack On May 12, 6:29 am, bji-gg...@ischo.com wrote: Quote: On May 12, 2:58 pm, Sebastian Redl <e0226...@stud3.tuwien.ac.at wrote: Now GCC (both 3.x and 4.x) put the vtable pointer before the base subobject, but there really is no reason why they should. A compiler might well put the base subobject first and the vtable pointer second. This means that the vtable is at an offset of sizeof(int) in Foo, but the compiler expects it at an offset of 0 in Rtti, leading to an incorrect dereferencing. I believe GCC 2.x had a very different layout in the face of RTTI that would break your example. I think I read somewhere that early GCC C++ compilers put the vptr at the end of an object. (However, this has so obvious drawbacks in the face of even simple inheritance that it was quickly changed.) Yes I am wondering how inheritence in object hierarchies with virtual methods worked at all in the scenario you describe for GCC 2.x. If I have a pointer to a B, which inherits from A, and both classes have a vtable ... There is only one vtable. Layout is like this: A data vptr to B table for A B data then if I cast the B to an A, and pass that to some method, Quote: how can that method know that it really has a B and that its vtable is located in a different location than it would be if it really and truly were an A? Because it knows layout for A. Compiler knows exactly where is vptr when looking for A vtable. That's why if you lie compiler about base class , program will crash. Quote: Assuming the precondition that the pointer passed in point to an object with a vtable, I have yet to hear convincing evidence that my hack won't work on every compiler. Just try it with g++ 2.95.2 Greetings, Branimir. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Sat May 12, 2007 9:10 am    Post subject: Re: C++ rtti hack bji-ggcpp (AT) ischo (DOT) com wrote: :: On May 12, 2:58 pm, Branimir Maksimovic <b...@hotmail.com> wrote: :: ::: Wrong. I tried same hack years ago and it didn't worked. ::: Particular compiler was g++ 2.95.2, and it didn't worked, because ::: that compiler lays vtable pointer behind class data. ::: So if you cast it to wrong base and you have some data in base ::: class, compiler will look up in wrong place and segfault. ::: I think that since 3.x version they changed that, and vtable pointer ::: is now always first, so that's why your hack appears to work. :: :: Thank you for your reply Branimir! :: :: I am a little confused on your example, but if what you are :: describing is a base class with no vtable, but a subclass with a :: vtable, then I have addressed this already in other replies. One of :: my preconditions of using the LookupTypeInfo method is that the :: pointer passed in must point to a class with a vtable. So if you :: are passing in a pointer to the base class in your example, then :: yes, it will seg fault - because the base class has no vtable. :: Which is OK by me, because you've violated one of the preconditions :: of the method. :: One of the freedoms of the implementation is that there are no requirements for a vtable at all. It is not mentioned in the standard. It is just a common way of implementing virtual functions. There could be others. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Bo Persson Guest Posted: Sat May 12, 2007 9:10 am    Post subject: Re: C++ rtti hack bji-ggcpp (AT) ischo (DOT) com wrote: :: :: 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? Is there a great value of closing the door for such compilers? :: :: 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 don't. :-) For polymorphic types it might be, but can most often be solved by using virtual functions. For pointers to non-polymorhpic objects, you program shouled be able to track the pointer better than "I have a pointer to some object". :: 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. The idea with C++ is that you should not give up performance for silly features that you don't use. The more restrictions you add to the details of the required implementation, the less room you leave for smart compilers. It is possible to have a C++ implementation on machines with 9 bit bytes, 36 bit integers, using ones complement, and 72 bit floating point. You don't have to have a hardware stack, and vtables are not required. C++ is this way, not by mistake but by design. If you want it the other way round, you could go with Java. Bo Persson -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Stephen Howe Guest Posted: Sun May 13, 2007 2:45 am    Post subject: Re: C++ rtti hack Quote: 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? AFAIK, there is mandate in the standard that RTTI and virtual functions have to implemented using vtables at all. The door is open for a compiler vendors to use other techniques. And it need not be malicious, the vendor might believe it gives them a competitive edge. All that is mandated is that it has to work according to what the standard requires. Stephen Howe -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Sebastian Redl Guest Posted: Sun May 13, 2007 2:45 am    Post subject: Re: C++ rtti hack On Fri, 11 May 2007 bji-ggcpp (AT) ischo (DOT) com wrote: Quote: 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? Absolutely. If there was a specification on where the vptr lies, you'd need to specify that a vptr and a vtable exist in the first place. Bad idea: if someone comes up with a better idea, they can't use it. In particular, in order to specify the exact place of all vptrs, you'd also have to specify the exact implementation strategy for multiple and virtual inheritance, neither of which is desireable: especially in the area of virtual inheritance, solutions superior to the existing might yet be found. Sebastian Redl -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Sebastian Redl Guest Posted: Sun May 13, 2007 2:47 am    Post subject: Re: C++ rtti hack On Fri, 11 May 2007 bji-ggcpp (AT) ischo (DOT) com wrote: Quote: 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? I just thought of another reasonable optimization that could break your system. Consider a compiler that does all of its optimization at link time. Consider further that the compiler can prove that it is aware of all code of the final executable, possibly because the target environment doesn't support dynamic loading of libraries. (Embedded targets come to mind.) Now the compiler might be aiming to reduce the size of the final executable. Since it is aware of all existing code, it might test the need for RTTI information. Now, there's a program using your RTTI system exclusively. The compiler sees that the only dynamic typeid call in the entire program is done on an Rtti. It therefore keeps the RTTI info for Rtti and its subclasses (none) and drops it for everything else. Oops. Sebastian Redl -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Sun May 13, 2007 2:59 am    Post subject: Re: C++ rtti hack On May 12, 9:16 pm, "Bo Persson" <b...@gmb.dk> wrote: Quote: bji-gg...@ischo.com wrote: :: :: 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? Is there a great value of closing the door for such compilers? Yes, if it enables other functionality that is more useful. This functionality is the whole point of what I am trying to do. Quote: :: :: 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 don't. :-) For polymorphic types it might be, but can most often be solved by using virtual functions. For pointers to non-polymorhpic objects, you program shouled be able to track the pointer better than "I have a pointer to some object". But I am writing a library, that takes "a pointer to some object", recovers type information on that object, and then acts on it. What you are suggesting is that I take "a pointer to some object that inherits from a class that is known to me". This would require everyone who wanted to use my API to inherit from a special base class that I define. I really don't want to require this; I think it's onerous to expect developers to inherit from a base class just to be able to use my API. I think that requiring the developers only use the API with polymorphic classes is unfortunate also, but this is something that I *know* that I CANNOT get around in the C++ language. rtti is very definitely specified to only work with polymorphic classes, and no amount of hacking I try to do is going to let me magically locate rtti information for classes that don't have it embedded in them. Quote: :: 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. The idea with C++ is that you should not give up performance for silly features that you don't use. The more restrictions you add to the details of the required implementation, the less room you leave for smart compilers. It is possible to have a C++ implementation on machines with 9 bit bytes, 36 bit integers, using ones complement, and 72 bit floating point. You don't have to have a hardware stack, and vtables are not required. I am not asking for the compiler to violate any of these things. I'm just asking the compiler to always make rtti locatable for any polymorphic object. I am also wishing that the C++ standard required this. And I am theorizing that modern compilers always *will* make rtti locatable for any polymorphic object. I am not preventing the compiler from making code work on any machine with any particular hardware features. Quote: C++ is this way, not by mistake but by design. If you want it the other way round, you could go with Java. I want what I think many other people want: a hybrid of C++ and Java that takes the "best" features of C++ (portability, open standardization, performance, "full control", etc) and the "best" features of Java (conciseness, simplicity, regularity of syntax, a reasonably complete standard library) and puts them in one language. I am trying to achieve this using C++ as a starting point, and simply restricting myself to using only those features of C++ that would make sense in such a language, and also adding some missing functionality to C++. The "hacks" that I am discussing in this forum are part of my strategy for the latter. Thanks, Bryan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Stephen Howe Guest Posted: Sun May 13, 2007 8:03 am    Post subject: Re: C++ rtti hack Quote: :: 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? Is there a great value of closing the door for such compilers? Yes, if it enables other functionality that is more useful. This functionality is the whole point of what I am trying to do. It has never been that way in C++ (or C) The standards give great latitude for how vendor implement things. If it was set in stone, it would leave no room for any additional improvements. A case in point is room for the empty base class optimisation, return value optimisation for copy constructors, where the size of new[] is recorded etc And over the years I have seen compiler vendors mae such improvements in their implementation of the C++ model. It would be a shame if they were unacceptably tied down. Quote: But I am writing a library, that takes "a pointer to some object", recovers type information on that object... If it is actually recoverable. There is a "If I dont use this feature, then I should have to pay for it" If you have not used type information for a class in a legitimate way, it maybe that the compiler/linker removes the information. Cheers Stephen Howe -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Guest Posted: Mon May 14, 2007 8:11 am    Post subject: Re: C++ rtti hack On May 14, 6:35 am, brang...@ntlworld.com (Dave Harris) wrote: Quote: I suspect the solution will involve templates. Possibly polymorphic template classes that are constructed when you know the object's exact type and accessed later when it isn't known. Or you may be able to register the object's address and type_info in a map for later lookup. This is a good idea. Anyway, the good arguments of all in this list have convinced me that what I am doing is not going to work. I will have to change my API to require the caller to pass in the type_info, rather than trying to have my library method look it up for them. I was hoping to avoid this, but I guess it is not possible. Thank you, Bryan -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.