static_cast thread safe?

Kellerautomat

ftfy schrieb:

reinterpret_cast ist super nützlich zur platformabhängigen, compilerversionabhängigen und compilereinstellungsabhängigen Serialisierung.

Ich finde es toll, dass du Code schreibst, der auf jedem noch so besonderen Mikrocontroller mit C++-Implementierung laeuft. Das ist mir bei meinen Programmen aber relativ egal.

Auf meinen Ziel-Plattformen ist:
- ein (u)intN_t genau N Bytes gross, in little-endian gespeichert und falls signed im 2er Komplement
- ein float/double in einem IEEE754-konformen Format

Ausserdem ist reinterpret_cast flott. Mag sein, dass der Compiler das optimieren kann, wenn ich Bitoperationen verwende. Spaetestens bei Fliesskommazahlen wirds dann aber schwer. Flotter als reinterpret_cast gehts wohl kaum. Zumal das genau das ausdrueckt, was ich tun moechte: "Gib mir die Bytes von diesem Ding."

Daher:

Kellerautomat schrieb:

Davon grundsaetzlich abzuraten halte ich fuer Mist.

Auf deinen sinnlosen Rechtschreibflame gehe ich mal nicht ein.

Eisflamme

Mal nochmal für mich: static_cast für native Typen ist eine Uminterpretation eines Wertes und kostet somit keine Laufzeit und ist somit immer threadsafe?

Eisflamme schrieb:

Mal nochmal für mich: static_cast für native Typen ist eine Uminterpretation eines Wertes und kostet somit keine Laufzeit und ist somit immer threadsafe?

Nein.
Bei double -> int muss gerechnet werden, weil die Bitinterpretation anders ist.
Ebenso int -> long, weil die oberen Bits genullt sein müssen.
float -> double ebenfalls.
signed -> unsigned hingegen nicht (Zweierkomplement vorausgesetzt)

Kostet aber nur minimal Laufzeit.

Threadsafe hat gar nichts damit zu tun. Schon das Lesen einer int-Variable ist nicht threadsafe (atomar)

Eisflamme

Habe gerade überlegt, wieso das dann nichts damit zu tun hat. Da fiel mir ein, dass man den Wert ja auch irgendwo benutzen muss, weil der Cast sonst sinnlos ist. Alles klar

Fuchs aus dem Wald

Eisflamme schrieb:

Habe gerade überlegt, wieso das dann nichts damit zu tun hat. Da fiel mir ein, dass man den Wert ja auch irgendwo benutzen muss, weil der Cast sonst sinnlos ist. Alles klar

Wow genau dieser Satz wird hier Augen öffnen.
Danke an die vielen Antworten! Hat mich weiter gebracht.

Marthog

eehnope schrieb:

Eisflamme schrieb:

Mal nochmal für mich: static_cast für native Typen ist eine Uminterpretation eines Wertes und kostet somit keine Laufzeit und ist somit immer threadsafe?

Nein.
Bei double -> int muss gerechnet werden, weil die Bitinterpretation anders ist.
Ebenso int -> long, weil die oberen Bits genullt sein müssen.
float -> double ebenfalls.
signed -> unsigned hingegen nicht (Zweierkomplement vorausgesetzt)

Kostet aber nur minimal Laufzeit.

Ich denke, in vielen Fällen kostet es sogar keine Laufzeitdifferenz, denn x87 FPUs haben 80bit große Register.
Bei double->int muss in ein Integer, beim Speichern in einer double-Variable muss von 80 bit auf 64 umgerechnet werden (FIST statt FST).
Oft wird der Geschwindigkeitsverlust sogar unter einem Takt liegen, eine Differenz auf die man selbst bei starker Optimierung verzichten kann.

Ethon

Ich verwende reinterpret_cast für 2 Anwendungsfälle:

1. Bei meinen Gamehacks:

uintptr_t const IS_SWIMMING_ADDRESS = 0xDEADBEEF;
*reinrterpret_cast<uint32_t>(IS_SWIMMING_ADDRESS) = true;

2. mit std::aligned_storage

Sone

Ethon schrieb:

mit std::aligned_storage

static_cast ?

Ethon

Sone schrieb:

Ethon schrieb:

mit std::aligned_storage

static_cast ?

static_cast<Foo*>(static_cast<void*>(bar));

Finde ich nicht wirklich besser.

Sone

Ethon schrieb:

static_cast<Foo*>(static_cast<void*>(bar));

Missverständnis.