typeinfo problem (bug?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi everyone,

I've run into a problem with std::type_info.

It appears that hidden visibility can cause multiple instances of a type_info object for one type, hence RTTI information is not being merged across SSO and DSO boundaries.  :-(

Is there an appropriate flag to specify to the compiler that will cause __GXX_MERGED_TYPEINFO_NAMES to be defined as 1?

I supposed I can just -D__GXX_MERGED_TYPEINFO_NAMES ... but I was under the impression that the __GXX_WHATEVER preprocessor defines shouldn't be twiddled by hand.

Perhaps I'm mistaken about refraining from specifying -D__GXX_WHATEVER on the g++ command line?

- - - - - - - - - - - - - - - - - - - - -

Also (incidentally & unrelated to the above), it is very weird that __GXX_MERGED_TYPEINFO_NAMES has two different semantics.  Specifying __GXX_MERGED_TYPEINFO_NAMES has two unrelated orthogonal effects:
1. are the before() and operator==() routines inline or function calls
2. are the before() and operator==() routines lightweight pointer compares or slightly more costly string compares

I'd like to have inline routines using __builtin_strcmp.  But I can imagine some situations where __builtin_strcmp is desired, but only as function calls and not inline.

Unfortunately...
__GXX_MERGED_TYPEINFO_NAMES == 0 means "strcmp & function calls".
__GXX_MERGED_TYPEINFO_NAMES == 1 means "pointer compares & inline".

There's no "strcmp & inline" (what I want), nor is there "pointer compares & function calls".  Hmmmm.

I'm using GCC 4.0.1, so perhaps this has been fixed by now.

Sincerely,
--Eljay


[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux