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: 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 
on?

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/