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/