std::atomic_bool vs. std::atomic<bool>

[Scott Meyers]

These types seem to have almost identical interfaces. The only
difference I see (in terms of functions that may be called -- I didn't
check the semantics of the functions) is that std::atomic<bool> offers

bool operator=(bool);

and std::atomic_bool does not. (It almost offers that function, but
it's volatile-qualified.)

Can somebody please explain why we need std::atomic_bool instead of
just using std::atomic<bool>?

Thanks,

Scott

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Bo Persson]

Scott Meyers wrote:
> These types seem to have almost identical interfaces. The only
> difference I see (in terms of functions that may be called -- I
> didn't check the semantics of the functions) is that
> std::atomic<bool> offers
> bool operator=(bool);
>
> and std::atomic_bool does not. (It almost offers that function, but
> it's volatile-qualified.)
>
> Can somebody please explain why we need std::atomic_bool instead of
> just using std::atomic<bool>?
>
> Thanks,
>
> Scott

They were initially added as an offer to the C language committee, for
a common interface.

Seems like the offer wasn't accepted.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.htm#header

Bo Persson

[Anthony Williams]

Scott Meyers <use...@aristeia.com> writes:

> Can somebody please explain why we need std::atomic_bool instead of
> just using std::atomic<bool>?

As I understand it, the std::atomic_xxx types are the "basic" atomic
types, provided for compatibility with the proposal to the C
committee. std::atomic<xxx> is the general case, which is then specified
to publicly derive from the corresponding atomic_xxx type where there is
one in order to allow interoperability (e.g. you can pass a
std::atomic<int>* to a function taking a std::atomic_int*)

So, the primary reason is potential C compatibility.

Anthony
--
Author of C++ Concurrency in Action | http://www.stdthread.co.uk/book/
just::thread C++0x thread library | http://www.stdthread.co.uk
Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

[Daniel Krügler]

On 24 Nov., 21:38, Scott Meyers <use...@aristeia.com> wrote:
> These types seem to have almost identical interfaces. The only
> difference I see (in terms of functions that may be called -- I didn't
> check the semantics of the functions) is that std::atomic<bool> offers
>
> bool operator=(bool);
>
> and std::atomic_bool does not. (It almost offers that function, but
> it's volatile-qualified.)
>
> Can somebody please explain why we need std::atomic_bool instead of
> just using std::atomic<bool>?

The type atomic_bool is provided as something that would be
compatible with C, because C is also going to develop a
threading library. You can recognize that from the free functions
that are also to provided to act on this type in the typical manner
for C (The atomic_* functions). In C the member functions of
atomic_bool would not exist, of-course. On the other hand,
one might ask, why C++ does specify any members of
the atomic_* types at all, because the atomic template
specializations would seemingly suffice.

HTH & Greetings from Bremen,

Daniel Kr�gler

[Scott Meyers]

Daniel Kr�gler wrote:
> On the other hand,
> one might ask, why C++ does specify any members of
> the atomic_* types at all, because the atomic template
> specializations would seemingly suffice.

So I'll ask: why?

And why not just define std::atomic_bool to be a typedef for std::atomic<bool>?

Scott