atomics noncopyable?
-
Kannst du ein Beispiel nennen, wie dadurch ein Fehler entstehen koennte? Bisher war das fuer mich immer nur laestig.
-
Man braucht keinen Kopierkonstruktor oder Assignment-Operator, um trivially copyable zu sein. Siehe 9 (6) in C++11:
A trivially copyable class is a class that:
- has no non-trivial copy constructors (12.8),
- has no non-trivial move construcots (12.8),
- has no non-trivial copy assignment operators (13.5.3, 12.8),
- has no non-trivial move assignment operators (13.5.3, 12.8), and
- has a trivial destructor (12.4)
-
Der Copy-Ctor ist explizit deleted...
-
seldon schrieb:
Man braucht keinen Kopierkonstruktor oder Assignment-Operator, um trivially copyable zu sein. Siehe 9 (6) in C++11:
A trivially copyable class is a class that:
- has no non-trivial copy constructors (12.8),
- has no non-trivial move construcots (12.8),
- has no non-trivial copy assignment operators (13.5.3, 12.8),
- has no non-trivial move assignment operators (13.5.3, 12.8), and
- has a trivial destructor (12.4)?
Man darf keinen haben.
-
Sone schrieb:
Man darf keinen haben.
Wo liest du das da?
-
Um seldons Zitate aus dem Standard noch zu vervollständigen:
Standard schrieb:
12.8.12 A copy/move constructor for class X is trivial if it is not user-provided, [...]
12.8.25 A copy/move assignment operator for class X is trivial if it is not user-provided, [...]8.4.2.4 [...] A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration.[...]
Es gelten noch ein paar mehr Einschränkungen (hab ich weggelassen), aber ein =delete hindert eine Klasse nicht am trivial-sein.
Sone schrieb:
?
Womit wir wieder beim Thema wären: einfach mal die Fresse halten wenn man nix zu sagen hat.
-
dot schrieb:
Sone schrieb:
Man darf keinen haben.
Wo liest du das da?
Na da steht doch -has no non-trivial copy ctor, oder nicht? Wie darf er dann da sein?
-
Genau das steht da. Die Klasse darf keinen nichttrivialen Copy Ctor haben...
-
dot schrieb:
Genau das steht da. Die Klasse darf keinen nichttrivialen Copy Ctor haben...
... Ja, und ein trivialer ist ein vom Compiler generierter. Und den meinte ich damit gar nicht.
Ich meinte, man darf keinen selbst definieren. Aber ich glaube, das war auch scheiße formuliert, aus dem Kontext her erschließt es sich natürlich falsch
Thx
Edit: Eisflamme, du musst nicht auf mich aufpassen.
-
Hat sich Dein Verständnisproblem mit dots Antwort jetzt erledigt oder nicht? Falls nicht, formulier doch um, falls doch, bedank Dich doch.
-
Ich hab jedenfalls nicht verstanden, warum man Copy Ctor explizit deleted.
-
standardbot schrieb:
Standard schrieb:
8.4.2.4 [...] A function is user-provided if it is user-declared and not explicitly defaulted or deleted on its first declaration.[...]
Es gelten noch ein paar mehr Einschränkungen (hab ich weggelassen), aber ein =delete hindert eine Klasse nicht am trivial-sein.
Das Gegenteil ist der Fall. Das not bezieht sich nur auf "explicitly defaulted" (wäre "explicitly defaulted or deleted" zu negieren, lautete die Formulierung eher "neither explicitly defaulted nor deleted").
Übrigens auch eindeutig an der entsprechenden Lösung erkennbar. Wäre es anders, könnte man jeden nicht-trivial kopierbaren Typen in ein struct packen, für dass alle speziellen Memberfunktionen deleted sind und erhielte etwas trivial Kopierbares (also etwas, auf das u.a. memcpy losgelassen werden kann), das ergibt keinen Sinn und würde auch einigen anderen Stellen des Standards widersprechen.In jedem Fall sehe ich nicht, was triviale Kopierbarkeit im Zusammenhang mit atomics bringen soll. Man würde fast unvermeidlich 1.10/25-UB verursachen.
-
camper schrieb:
In jedem Fall sehe ich nicht, was triviale Kopierbarkeit im Zusammenhang mit atomics bringen soll.
std::atomic verlangt, dass der verwaltete Typ trivially copyable ist (29.5 (1)).
Allerdings ist das, wo ich nochmal drüber nachdenke und n2427 etwas genauer lese, vermutlich nicht das, worum es hier geht (mea culpa). Dieser Absatz lässt mich vermuten, dass es um die Regel der Fünf geht:
We also provide the common fetch-and-modify operations. The fetch-and-modify functions return the original stored value. The original stored value is required for fetch-and-or and fetch-and-and because there is no means to compute to the original stored value from the new value and the modifying argument. In contrast to the functions, the fetch-and-modify assignment operators return the new value. We do this for consistency with normal assignment operators. Unlike normal C++ assignment operators, though, the atomic assignments return values rather than references, which is like C. The reason is that another thread might intervene between an assignment and a subsequent read. Rather than introduce this classic parallel programming bug, we return a value.
Aus diesem Grund gibt es keine normalen Zuweisungsoperatoren, und ohne Zuweisungsoperatoren sind Kopier- respektive Move-Konstruktoren eine gefährliche Idee.
Man könnte darüber nachdenken, ob std::atomic Zuweisungsoperatoren anbieten könnte, die einen std::atomic by-value zurückgeben (wofür man dann einen Kopierkonstruktor bräuchte), aber die Verwendung des Rückgabetyps wäre wohl eine ziemlich verwirrende Angelegenheit.
