Re: [Boost-users] Signals2 benchmark

Subject: Re: [Boost-users] Signals2 benchmark
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2015-02-11 09:34:35

On Tue, Feb 10, 2015 at 8:51 PM, Niall Douglas
<s_sourceforge_at_[hidden]> wrote:
> 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 <sys/types.h>
> #include <sys/sysctl.h>
> #include <sys/user.h>
> #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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users