On 15/11/2013 12:11, Quoth Niall Douglas:
Unfortunately typeid() does NOT necessarily return the same type_info instance for some type if done across DLL or shared object boundaries. This is because the compiler generates static type_info instances only for those types where typeid() is used (with weak or selectany linkage), and the linker links them up as if they were any ordinary structure instance. That means a copy per DLL/SO.
True, but how often does generation and comparison of a typeid actually need to cross DLL/SO boundaries? (Storage might, but generally that's just as an opaque value.) Typically usage would either be fairly localised or would be in templates -- and while it's possible to export and import templates across DLL/SO boundaries, it's usually not actually done. Granted I'm coming at this mostly from an application perspective, so I am probably unaware of exactly how Boost libraries want to use these.
Me personally I'd prefer name() to always return the mangled name on every platform so it's portable and consistent. Unless one is using a quirks type shim not called boost::type_info.
I kind of see that the other way around -- if you want to call something "type_info", then it ought to behave as close as possible like the standard "type_info" (albeit with some extras). If you want different behaviour you should give it a different name. :)
Remember that boost::type_info is not intended to be an exact replacement for std::type_info. It is expected that Boost code using std::type_info will need "porting" to boost::type_info. Antony has provided all the necessary patches required for many Boost libraries.
I have received the opposite impression from discussion thus far. Perhaps I have misinterpreted something.
On non-MSVC compilers, merely the attempt to access or create a type_info would generally cause a compiler error if RTTI is disabled. I therefore think that in this use case boost::type_info can merrily do whatever it feels like, with any API definition it feels like including returning std::string from name(). After all, the code didn't compile at all before, so no backwards compatibility is needed here - if it compiles at all and no semantics are broken, who cares?
I didn't mean it quite like that. I meant that people might be approaching this as "here's some code that works with standard RTTI", "here's a library that emulates typeid with RTTI disabled", "let's just plug them in!". Granted that the actual results may vary (different strings returned, not able to get the dynamic type without RTTI), but these seem like "unsurprising" sorts of changes. typeid also makes certain guarantees about lifetime that existing user code would be assuming, and might be surprised if these are not met. Again, if it's not being positioned as a drop-in then it's less of an issue (but means more user code might need to be changed). But then if it's not being positioned as a drop-in then I don't know why it's derived from std::type_info and doing the casts the way it is. Maybe there's some other reason for that?