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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-14 03:25:51

On Thu, Nov 14, 2013 at 11:48 AM, Antony Polukhin <antoshkka_at_[hidden]> wrote:
>
> Unfortunately, boost::type_info must derive from std::type_info for
> compatibility reasons. Without it the following code won't compile:
>
> std::type_index ti = boost:type_id<int>();
>
> This may look like a rare case, however will be quite common if other Boost
> libraries adopt the TypeIndex.

I think the above need not to work. After all, you don't expect this to work:

  std::shared_ptr< int > p = boost::make_shared< int >(10);

It should be no problem with sticking to boost::type_index and
boost::type_id in Boost libraries, and for user's code we could
provide means to convert between boost::type_index and
std::type_index.

> Is my favorite example with Boost.Any:
>
> boost::any a = 10;
>
> // Imagine that Boost.Any uses boost:;type_info instead of std::type_info
> class_that_constructs_from_std_type_info = a.type();
>
> // operator const std::type_info&() won't help
> std::type_index ti = a.type();

Boost.Any can use boost::type_index internally and a.type() can still
return std::type_info const& for backward compatibility. We just need
a method such as this:

  std::type_info const& boost::type_index::get() const;

> Why there is a such need in drop-in replacement? Here are the reasons:
>
> * some compilers fail to compare std::type_info across modules (surprise!)
> * some libraries fail to write a sane hashing function for std::type_info
> * users want to use Boost without RTTI and fail:
> http://stackoverflow.com/questions/14557313/is-it-possible-to-use-boost-program-options-without-rtti
>
> Here are some more issues in Boost:
> * there is a mess with stripping/not stripping const, volatile, reference
> * there is a mess with name() calls, plenty of places where name() used for
> debug/user output without demangling
> * some of the Boost libraries demangle names by themselfs and forget to
> dealocate memory (at least valgrind says so)
>
> In three words: std::type_info is broken.

I think that these problems can be tackled by just having
boost::type_index and boost::type_id. boost::type_index can implement
the name functions we discussed and offer interfacing with
std::type_info and implement workarounds for its bugs. boost::type_id
(or preferably its variations) can solve problems with
cv-qualification, references and visibility by wrapping the type
before constructing boost::type_index.

The only reason for boost::type_info I see is to emulate RTTI when
it's disabled. But as I see in the code, it is just an alias for
template_info in this case. So perhaps we should just make it that -
an alias to std::type_info or boost::template_info, depending on the
configuration. This way it will just allow to use the type_info type
portably, without preprocessor checks everywhere.