Boost logo

Boost :

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-14 15:06:52

On 14 Nov 2013 at 0:04, Andrey Semashev wrote:

> I don't like the idea of having two practically equivalent classes which
> basically do the same thing. The difference between the classes would be in
> the behavior, which is not specified by the standard in the first place and
> can be adjusted in a non-breaking manner in a unified boost::type_info class.

Taking off my peer review manager hat:

I see there being a base boost::type_info class, with quirks adapters
for backwards compatibility deriving from it. Such quirk adapters
would be extremely thin (basically changing what name() does, and a
few other minor changes).

Regarding the standard's definition of type_info, that is unimportant
here except where some boost::type_info_something is declared to
behave exactly like std::type_info. If we explicitly declare that
boost::type_info is intended as being superior to the standard and
therefore a breaking change from it, I see no issue.

Someone will now mention that because boost::type_info derives from
std::type_info that one cannot safely change its API. And this was
exactly my original point: a boost::type_info_something capable of
directly substituting according to the C++ type rules for
std::type_info MUST replicate as a minimum what the C++11 standard
says AND what the local implementation std::type_info does, including
quirks. Otherwise you get the problem that one compiland using
std::type_info will segfault when it encounters a boost::type_info
from another compiland which has been auto-converted to
std::type_info by the compiler.

Quite separately from this is where the programmer intentionally
replaces std::type_info with boost::type_info and the program
compiles and executes correctly because boost::type_info has been
cleverly designed to do so AND the programmer understands what that
means. That's a compile-time compatible type_info, which is very
different from a run-time compatible type_info.

Putting back on my peer review manager hat, I'd like to thank the
list for such a useful debate. It's certainly helped me see aspects
of the library I had not previously considered. I'll try to produce
an interim report this weekend to help frame the discussion during
the last five days of review.


Currently unemployed and looking for work.
Work Portfolio:

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