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: Antony Polukhin (antoshkka_at_[hidden])
Date: 2013-11-13 04:10:42

2013/11/13 Gavin Lambert <gavinl_at_[hidden]>

> On 13/11/2013 20:22, Quoth Antony Polukhin:
>
>  Names have "_rtti_only" to warn user that this call requires RTTI. This
>> must ring a bell and user may switch to type_id<D> version, which is more
>> portable. type_id_rtti_only is more explicit, so I like it more. But if
>> there'll be many recomendations during review period to switch names to
>> boost::type_id, I'll do that.
>>
> [...]
>
>  Names were given according to the following logic:
>> * TypeIndex library promises that it works without RTTI
>> * calls that do not work without RTTI must be explicitly marked
>> * calls that do work without RTTI - is just what was promised by the
>> library, no need to explicitly mark that the call does not requires RTTI
>>
>
> Couldn't this be resolved by changing the first to "TypeIndex library
> promises to be an enhanced implementation of standard typeid".
>
> Then you could just use:
>   * boost::type_id<Type>()      // typeid(Type)
>   * boost::type_id(variable)    // typeid(variable)
>
> Both would work with or without RTTI but the second would only report the
> declared type of the variable in the absence of RTTI (which is what typeid
> does for sliced value types anyway).
>

This looks very error prone. In current implementation disabling RTTI leads
to compile errors in case of an attempt to determinate type at runtime.
Using your approach code will compile, behavior of functions will silently
change and user will be debugging the application. Or even won't find the
issue and release a bogus program.

> Granted that you're no longer being explicit about RTTI safety or not in
> the actual method name, but I would hope that library authors who wish
> their libraries to work either way would test accordingly, so it should not
> matter.
>

Why force them to test code for errors, that can be detected and avoided at
compile-time?

> It seems to me that you're already aiming "higher" than bare-bones no-RTTI
> support with this library, with the name demangling and cv-preservation
> features for example.  (Though please see my other reply regarding
> demangling.)
>

Well may be a little bit :)
But those features are widely used and looks like type_info is the correct
place for them.

-- 
Best regards,
Antony Polukhin