atomic_bool a = static_cast<bool>(b);

WHYYYYYYYYYYY

std::atomic_bool a(static_cast<bool>(b));

funktioniert.

Übrigens sehe ich in Tobis Post keinen Cast, der in deinem Versuch nicht auch schon enthalten war.

Der Grund wird sein, dass std::atomic trivially copyable bleiben soll, um aus std::atomics zusammengesetzte structs wieder in std::atomic werfen zu können.

Da ist ein Widerspruch drin. Copy-ctor und copy-assignment von atomic-Typen sind immer deleted.

persönlich sehe ich nicht viel Sinn darin - atomics sind ihrem Zweck nach keine Value-Typen - diesen Typ kopierbar zu machen. Umgekehrt entsteht so nur eine Menge zusätzliches Fehlerpotential.

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 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.

Man darf keinen haben.

Wo liest du das da?

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.

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...

... 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.

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.

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.