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-14 07:08:31

2013/11/14 Andrey Semashev <andrey.semashev_at_[hidden]>

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

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