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/