Boost logo

Boost :

Subject: Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-01-13 05:09:42

On Sunday 13 January 2013 00:15:23 Vicente J. Botet Escriba wrote:
> Le 12/01/13 19:50, Andrey Semashev a écrit :
> > On January 12, 2013 9:57:22 PM "Vicente J. Botet Escriba"
> >
> > <vicente.botet_at_[hidden]> wrote:
> >> Andrey, the provided patch goes too far for what I was expecting. You
> >> have made a lot of changes, C++11 interface has not been preserved, and
> >> I'm not sure the algorithm is the same.
> >
> > The algorithm is different for sure. What exactly do you mean by C++11
> > interface? Does C++11 have call_once? The only C++11 thing I saw was
> > the once_flag definition which gave no apparent benefits.
> C++11 defines the following interface. There is no STD_ONCE_INIT
> initializer.
> struct once_flag {
> constexpr once_flag() noexcept;
> once_flag(const once_flag&) = delete;
> once_flag& operator=(const once_flag&) = delete;
> };
> template<class Callable, class ...Args>
> void call_once(once_flag& flag, Callable func, Args&&... args);
> Could this once_flag be implemented using the trick you used to mask the
> atomic dependency on the header file?

Hmm, I didn't know the standard defined call_once.

It is possible to define once_flag as defined by the standard. But the
previous implementation seem incorrect to me. once_flag *must* be either POD
or have a constexpr default constructor while the previous code (as well as
the code in win32/once.hpp) uses BOOST_CONSTEXPR which can be empty.
BOOST_THREAD_PROVIDES_ONCE_CXX11 macro doesn't depend on constexpr or noexcept
availability so it can't be used to enable C++11 implementation.

So in order to implement C++11 interface there has to be a macro that depends
on both constexpr or noexcept availability. Then the once_flag definition
should use constexpr and noexcept unconditionally.

Boost list run by bdawes at, gregod at, cpdaniel at, john at