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-15 18:55:38

On 16 Nov 2013 at 3:20, Andrey Semashev wrote:

> Ignoring the problem is not acceptable for a new library, IMO. The fact that
> some select compilers currently bear with such code doesn't mean they won't in
> the future, let alone there may be compilers that break it already.

The point is moot as I have decided to recommend against this UB
anyway. But unless my understanding of compiler technology is
completely incorrect (and I am open to being corrected by a compiler
vendor), I really don't think this particular UB if it were static
only is a concern until a new C++ standard appears, and even then, a
recompile would be needed to introduce breaking behaviour (at which
point we can fix up the implementation for the new standard). This is
my opinion of course, and if the review wizards disagree then I have
no issue.

> Putting
> that kind of jeopardy in the base of the library design is not a good solution
> by any measure. More so, when a cleaner solution is available.

The cleaner solution is not cost free - specifically, we now have to
expend an extra eight (and probably sixteen) static bytes of
additional binary size per type id i.e. code bloat. Personally, if it
weren't for the virtual tables issue, I'd consider this particular UB
worth saving that extra static memory consumption. It's not like this
UB is hard to undo later if needs be.

Given this extra bloat, we now have a new question: it is now worth
making boost::type_info completely always std::type_info free i.e. it
always uses the const char string from std::type_info::name() (or
raw_name()) directly, and otherwise completely skips interacting with
std::type_info at all? That ought to avoid having the linker emit a
static std::type_info as it ought to spot it being unnecessary and
elide it. That hopefully ought to substitute boost::type_info bloat
for std::type_info bloat in a roughly balancing manner, so there is
no net gain.

Antony: you mentioned that your type_info needs to interop with
std::type_info, and hence the need for convertibility? Can you
explain that in more detail please? Can type_info be always set to
template_info even with RTTI on, except that template_info will use
std::type_info::name() instead of __PRETTY_FUNCTION__ when RTTI is


Currently unemployed and looking for work.
Work Portfolio:

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