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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-15 16:22:11

On 15 Nov 2013 at 13:44, Gavin Lambert wrote:

> 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.

I beg to differ! A classic example is Boost.Python where more than 
one Python extension DLL module is loaded, both with a dependency to 
the same Boost.Python DLL instance. Boost.Python's type registries 
correctly store and compare mangled strings to cope with this quite 
common situation.

> > 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. :)

Yes and no. There is semantic equivalence, API equivalence and ABI 
equivalence. They're all not necessarily the same thing.

I personally don't mind a type_info which fixes the mistakes in the 
standard type_info if it causes the compiler to puke instead of 
hidden misoperation.

There is something to be said for eliminating the name() function 
altogether actually as its meaning is too vague and non-portable. 
Removing it in boost::type_info guarantees that the porting effort 
makes the author choose exactly what they mean with all the runtime 
costs implied (e.g. a demangled type string is usually run time 
calculated and longer than a mangled type string).

> > 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.

People jumped in with their particular preferred angles, as is normal 
during peer review. Also as is normal during peer review the 
relevance of the discussion to the library being reviewed can become 
quite tenuous. In this situation we've had a very good, and very 
useful (to me as the review manager) discussion. It helps hugely the 
library is so small and single purpose.

> 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?

Antony was trying to save on code bloat, amongst other things. The UB 
based implementation had the huge benefit of zero bloat with RTTI on. 
I think unfortunately considering the rationale I gave in a previous 
message we probably can't go with that, it's too UB due to the 
virtual function table mismatch.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/