Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

2013/11/14 Andrey Semashev

On Thu, Nov 14, 2013 at 11:48 AM, Antony Polukhin 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-prog...

...

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.

We are arguing about class type_info: public std::type_info { ...}; vs class type_info{ const std::type_info* ptr_; public: const std::type_info& get(); ... }; typedef ... std_type_info_if_exist_t; Can you explain me once more, what are the advantages of the second solution? -- Best regards, Antony Polukhin