|
Boost : |
Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th 21st 2013
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-27 17:42:52
On 27/11/2013 20:07, Quoth Niall Douglas:
> No it wasn't and isn't. That idea was all mine. I have bad memories
> of fighting precompiled binary blobs with stupid options you see, and
> I can see a very valid use case being mixing up RTTI on and RTTI off
> code. A method for interop here would be really useful, especially as
> it's so cheap to implement. I agree it lacks a "business case" right
> now though.
I can see that this *could* happen but having never run into it myself
I'm not sure it's worth the pain it seems like it'd be to try to work
around it.
Mind you, I've yet to find a need to pass type information across DLL/SO
boundaries either. Maybe I just need to get out more. :)
> Sure. I had in mind my unique_name() static initialiser would simply
> yank name() from std::type_info where that was available mainly
> because it's less code bloaty (MSVC always, GCC with RTTI on).
You do need to be careful with that one. While MSVC's typeid does still
exist with RTTI off, it's only half reliable. Calling it on any purely
static type works fine, but calling it on a polymorphic type (anything
where the declared type of the pointer/reference includes a vtable)
results in UB (typically a segfault). (Though it does generate a
compiler warning in this case, so it's not totally unheralded.)
Where used with user-provided types (eg. boost::any) that's likely to be
a recipe for Fun.
(Well, technically the call to typeid succeeds but it returns an invalid
object reference, so any attempt to call name() or any other member on
it will trigger UB. You might still be able to get away with comparing
pointers to the type_info, though I'm not sure if that would produce the
desired results anyway.)
> Ok, I leave for the US for Thanksgiving in a few hours, so I probably
> am off list for a good while. Happy Thanksgiving every one.
Happy Thanksgiving!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk