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 15:17:21

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

> On Wednesday 13 November 2013 12:44:54 Niall Douglas wrote:
> > Can I suggest this instead: instead of making boost::type_info more
> > like the flawed std::type_info, can you leave boost::type_info to be
> > pure and instead add a new boost::type_info_std or something which
> > does replicate std::type_info's implementation specific quirks?
>
> I don't see the point in such duplication. boost::type_index will only work
> with boost::type_info anyway.
>

boost::type_index and std::type_info can be compared with each other.
boost::type_info is derived from std::type_info and it can be used in any
method that accepts std::type_info.

Let me put the question in other way: do we want to support MS extensions?
If yes, then advantages are:
* less user code will be broken during conversion for std:;type_info to
boost::type_info (see for example boost::any::type())

Disadvantages:
* supporting vendor specific extensions is a bad practice
* we loose the meaning of name() as a "fast short nonreadable name" and get
something indeterminated instead
* more functions => more fuss for the user
* calls to name() will become slower on MS Windows

Let's change the balance in a following way (NEW WAY):
* const char* name() // same as std::type_info::raw_name()
* const char* raw_name() // // same as std::type_info::raw_name()
* std::string pretty_name() // was name_demangled()

Now we have following advantages:
* less user code will be broken during conversion for std::type_info to
boost::type_info (see for example boost::any::type())
* we do not loose the meaning of name() as a "fast short nonreadable name"
and do not get indeterminated faunctions instead
* calls to name() are fast

Disadvantages:
* supporting vendor specific extensions is a bad practice
* more functions => more fuss for the user
* calls to name() on MSVC will return different result (however name() may
return whatever it whants, according to Standard)

But do we *really* want to encourage users that write unportable code?

-- 
Best regards,
Antony Polukhin