Boost logo

Boost :

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-13 02:47:35

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

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.

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

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