On 10 Feb 2015 at 17:22, Gottlob Frege wrote:
Parts of Boost have these ODR issues if you are not careful. Other parts don't. So you need to "do it right" when designing/implementing the API.
GCC 5.0 is going to start optimising on the basis of ODR, as in code
which breaks ODR gets optimised in undefined behaviour ways. Thinking
about my own code where I routinely have violated ODR in source files
for convenience under the assumption that source files have limited
interactions with other source files, this could turn into a real
nest of vipers akin to aliasing bugs.
Indeed only last night I violated ODR! FreeBSD's sysctl headers which
represent the kernel API most unfortunately define a struct thread.
This definition causes ambiguity with std::thread and boost::thread,
so to work around it I wrapped the BSD sysctl headers with:
#define thread freebsd_thread
#include
It sounds like Nigel has convinced Nevin that for a hypothetical thread-safe + non-thread-safe "Signals3", we could/would do it the right way.
Nigel? Did we or did we not work together in the same office and team for ten and a half months??? :) Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/