Boost logo

Boost :

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.


Currently unemployed and looking for work.
Work Portfolio:

Boost list run by bdawes at, gregod at, cpdaniel at, john at