Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| 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> |
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 | Next — Previous in thread | Find similar
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