Volatile copyable not trivially copyable?

[Al Grant]

Given a POD struct type, say struct S { int a; };
it was always the case that if you wanted to be able to
assign to a volatile S, you had to explicitly define a
volatile-qualified copy-assignment operator:
operator=(S const&) volatile;
But this makes S "not trivially copyable". And in C++11
that means you can't instantiate std::atomic<S>.

Have I missed something? It seems strange that if I
want to wrap a primitive type in a class for abstraction
reasons (in an OS maybe) the class can either be
volatile-qualified and assigned freely, or used as the
basis for an atomic type, but not both. After all, there's
no such restriction on primitive types.

As a constructive suggestion, would there be any
consequences if the standard were to permit defining
operator=(S cv-qualifiers&) volatile = default;
and consider it a trivial copy assignment operator?


--
[ comp.std.c++ is moderated. To submit articles, try posting with your ]
[ newsreader. If that fails, use mailto:std-cpp...@vandevoorde.com ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

[Daniel Krügler]

Am 25.03.2012 01:55, schrieb Al Grant:
>
> Given a POD struct type, say struct S { int a; };
> it was always the case that if you wanted to be able to
> assign to a volatile S, you had to explicitly define a
> volatile-qualified copy-assignment operator:
> operator=(S const&) volatile;
> But this makes S "not trivially copyable". And in C++11
> that means you can't instantiate std::atomic<S>.

Correct.

> Have I missed something? It seems strange that if I
> want to wrap a primitive type in a class for abstraction
> reasons (in an OS maybe) the class can either be
> volatile-qualified and assigned freely, or used as the
> basis for an atomic type, but not both. After all, there's
> no such restriction on primitive types.

I'm not sure what precisely you mean with you comparison with
primitive types, but let me point out that there is since quite a long
time issue 496 in progress:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#496

which would have the effect to make all volatile-qualified objects
non-trivial. This is somehow a logical conclusion, since it was always
clear (but not really clarified what the meaning of an object access
to a volatile object is) could be far from trivial. If you look at the
rationale for the C++ rule that exists since 1998 "Change: Copying
volatile objects", you will notice that similar concerns lead to this
restriction decision.

> As a constructive suggestion, would there be any
> consequences if the standard were to permit defining
> operator=(S cv-qualifiers&) volatile = default;
> and consider it a trivial copy assignment operator?

If #496 would be applied, I don't see how such a rule could be reasonably added.

My suggestion would be to add a volatile member function to your class
type that performs the copy to the volatile object and let the
compiler add the implicitly-declared (trivial) copy-assignment
operator.

HTH & Greetings from Bremen,

Daniel Krügler