Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-14 19:44:34

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?