Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?

Subject: Re: [boost] [thread] Can Boost.Thread use Boost.Atomic without falling on a compatibility issue?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-13 10:08:28

Le 13/01/13 11:09, Andrey Semashev a écrit :
> 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.

Could you work on complementing your patch to take care of the C++11 
interface?
> 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.
Andrey, could you explain me why once_flag must be either be a POD or 
follow strictly the C++11 interface? In other words, what are the 
problems defining it as follows?

struct once_flag {
    once_flag();
private:
    once_flag(const once_flag&);
    once_flag& operator=(const once_flag&);
};

Best,
Vicente