Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c++ > #469

Re: Volatile copyable not trivially copyable?

From Daniel Krügler <daniel.kruegler@googlemail.com>
Newsgroups comp.std.c++
Subject Re: Volatile copyable not trivially copyable?
Date 2012-03-25 23:14 -0700
Organization A noiseless patient Spider
Message-ID <jkmpv6$lg6$1@dont-email.me> (permalink)
References <c86fa57d-ffdf-4b3e-bb5f-bd5f6eb0bb0e@q11g2000vbu.googlegroups.com>

Show all headers | View raw


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



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

Back to comp.std.c++ | Previous | NextPrevious in thread | Find similar


Thread

Volatile copyable not trivially copyable? Al Grant<algrant@myrealbox.com> - 2012-03-24 17:55 -0700
  Re: Volatile copyable not trivially copyable? Daniel Krügler <daniel.kruegler@googlemail.com> - 2012-03-25 23:14 -0700

csiph-web