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: http://careers.stackoverflow.com/nialldouglas/