I have read about many issues associated with RTTI. People go back and forth on it as far as performance, but as I already use exceptions, I don't much care since I'm already eating most of the performance/memory penalty for it. What I'm very concerned about is the behavior across DLLs. I understand that if I use typeid(T) on two different types that live in different DLLs, I can get matching type_info pointers when the types are not the same. This issue I only know about because I was lucky enough to stumble across it in another post, and even when actively looking for these sorts of RTTI shortcomings I don't get very relevant results. So I have some questions: - Can typeid(T) return non-matching type_info* structs if the types are the same but in two DLLs? - Is there a way to tell what module (i.e. dll/so) a type_info* is coming from at runtime based on the pointer address? - Before the compile, can I tell by looking at the code what module a type will belong to? Is it possible to have the type belong to multiple modules? - Are there other issues I should be aware of similar to these? And are there ways to mitigate them? I read about the fallback to string comparisons that can be used: http://lists.boost.org/Archives/boost/2006/10/111781.php Thanks

Quote:I have read about many issues associated with RTTI. People go back and forth on it as far as performance

There is no performance overhead in using RTTI.

Quote:but as I already use exceptions

A good implementation of exceptions (ie. a non-windows one) has no performance overhead in the case where no error is thrown.
Actually, exceptions are much faster that alternative error handling solutions, such as if/else and return codes, because the case where no error occurs (which should be 95% of the time) is optimized.

Quote:What I'm very concerned about is the behavior across DLLs.

C++ has no notion of "DLL".
Therefore the behaviour is not defined. What happens is probably implementation-specific.

Quote:I understand that if I use typeid(T) on two different types that live in different DLLs, I can get matching type_info pointers when the types are not the same.

Looks like your implementation didn't try to make RTTI play well with its "DLL" mechanism. That's understandable, though.

I suppose different compilers and platforms do different things. I honestly do not know much about that subject, since I don't use dynamic libraries myself, but I advise you to not expect anything.

I am not interested in turning this into a performance/pros/cons thread, as I said first thing.

For clarity, by DLL I mean whatever dynamic linking mechanism that happens to be on the target OS. I would like to support msvc, gcc, and try to be standard enough that any other modern compiler should be expected to work fine.

From my understanding, .so files on linux have the same sorts of issues. And btw, I'm sure almost any implementation of dynamic linking is going to have some quirks, simply because the dynamically linked code at compile time has no way to guarantee uniqueness between modules. What I'm looking for here is to find out about as many gotchas up front as possible, and to confirm that what I *think* is right, is correct, before I get too invested into my own ignorance. :)

Quote:Original post by Hodgman
From what I remember, type_info's name function will return different strings depending on the compiler that was used, *but* it's == operator always works.

Quote:I understand that if I use typeid(T) on two different types that live in different DLLs, I can get matching type_info pointers when the types are not the same.

Even if this is true (which I don't think it is), you shouldn't be comparing the pointer values anyway!
You should be comparing the actual type_info objects themselves (using their overloaded == operator).

Good point on the ==s. I need to go double-check that that's how I'm testing for equality.

I decided to go back and re-read what I had found that led me to my conclusion about type_info non-uniqueness across DLLs:
http://www.gamedev.net/community/forums/topic.asp?topic_id=479183

The comment by dmail at the end concerns me. The page he linked makes it seem that boost python developers decided that string comparisons of the name are safer than the == comparison on GCC and a couple other platforms (not MSVC though). I am wondering if I'm going to have to adopt a similar strategy, and that's what got me to thinking there might be some other nasty traps I don't know about.

But of course, if this is not true, (which would explain why SiCrane made no mention of it in that post, and why I could not find any additional information about this) then I would be very pleased. :)

Thanks!