On Tue, Feb 10, 2015 at 8:51 PM, Niall Douglas
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
#include #include #undef thread
Here it's clear what we're talking about. Apologies to the list for my confusion.
Probably safe, but still an ODR violation :(. That's how easily riddled with ODR a large mature C++ code base can become.
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/
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users