ZFX + Developia

float LiesFloat() { 
  uint32_t bits = LiesBits(32); 
  return reinterpret_cast<float&> (bits); 
}

gcc hat geschrieben:../../Traumklassen/TBitLeser.h96: warning: dereferencing type-punned pointer will break strict-aliasing rules (-Wstrict-aliasing)

FlorianB82 hat geschrieben:Die meisten aktuellen C++-Compiler führen keine Optimierungen aufgrund der Strict-Aliasing-Rules durch - da sollte also trotz der Warnung kein unerwartetes Verhalten aufgrund Optimierung auftreten. Soweit ich aber weiß, führen neuere GCC-Versionen solche Optimierungen durch - hier könntest du dann gegebenenfalls interessante Effekte beobachten.

int blub(int* i, float* f)
{
  *i = 10;
  *f = 32.0f;
  return *i + *f;
}

int main()
{
  union
  {
    float f;
    int i;
  } x;
  
  return blub(&x.i, &x.f);
}

FlorianB82 hat geschrieben:Wenn du die Warnung vernünftig losbekommen willst - was ich nur begrüßen kann, da ich ein großer Freund von Warning-Free-Code bin - gibt es immer die Möglichkeit, über einen char-Pointer (signed oder unsigned) zu casten. Gemäß der Strict-Aliasing-Rules dürfen (unsigned/signed) char*-Pointer nämlich jeden beliebigen Typ aliasen, und du bist damit safe und standardkonform.

FlorianB82 hat geschrieben:Über einen Union zu gehen ist eigentlich auch Murks. Interessant, dass der Compiler da nicht meckert. Wenn mich nicht alles täuscht, erlaubt der C++-Standard nur das Lesen aus einem Feld eines Unions, in das man vorher auch geschrieben hat - alles andere ist UB. Da du das aber genau machen würdest (in i schreiben und aus f lesen), kannste dir das auch sparen. Ist auch nicht besser oder schlechter als der brutalo-cast.

dot hat geschrieben:Die Strict-Aliasing-Rule ist Grundnahrungsmittel jedes auch nur annähernd brauchbaren Compilers und für die Performance von C++ von essentieller Bedeutung.

1. Kapsle das in einer Funktion – bloß nicht an jeder Stelle, an der du ein float liest, diesen union-Kack und die enstprechenden #if __GCC__ reproduzieren (machst du sowieso nicht, aber hier lesen ja noch andere mit)
2. Diese Funktion sollte auf keinen Fall Referenz oder Zeiger zurückgeben, sondern unbedingt eine neue Instanz – sonst produzieren viele Compiler tatsächlich jede Menge nutzlose Loads und Stores, sobald du mit dem Wert arbeitest

Krishty hat geschrieben:

dot hat geschrieben:Die Strict-Aliasing-Rule ist Grundnahrungsmittel jedes auch nur annähernd brauchbaren Compilers und für die Performance von C++ von essentieller Bedeutung.

Die Strict Aliasing Rule ist nur für GCC von essentieller Bedeutung. Und sie ist grundsätzlich falsch (weil C++ das Re-Instanzieren einer Variable am alten Platz mit neuem Typ erlaubt) und die GCC-Leute haben, als sie das gemerkt haben, einfach beschlossen, sie doch drin zu lassen weil sie in 99 % der Fälle halt funktioniert (indem sie den User sinnlos nervt). Ich sehe das als bloße Schikane.

Schrompf hat geschrieben:Hm. Klingt für mich, als wäre ich im UB, egal was ich tue. Ich habe hier aktuell die union-Lösung implementiert, die zumindest auf dem GCC warnungsfrei kompiliert und das tut, was sie soll. Ein Hoch auf Unittests. Ob und wie sich Visual Studio damit schlägt, werde ich jetzt aber so schnell nicht herausfinden. Und den entstehenden ASM-Code werde ich mir am Ende eh zu Gemüte führen müssen, da das Manöver u.A. Teil meines Voxelkrams ist, der potentiell Gigabytes davon durchackert.

dot hat geschrieben:

Krishty hat geschrieben:

dot hat geschrieben:Die Strict-Aliasing-Rule ist Grundnahrungsmittel jedes auch nur annähernd brauchbaren Compilers und für die Performance von C++ von essentieller Bedeutung.

Die Strict Aliasing Rule ist nur für GCC von essentieller Bedeutung. Und sie ist grundsätzlich falsch (weil C++ das Re-Instanzieren einer Variable am alten Platz mit neuem Typ erlaubt) und die GCC-Leute haben, als sie das gemerkt haben, einfach beschlossen, sie doch drin zu lassen weil sie in 99 % der Fälle halt funktioniert (indem sie den User sinnlos nervt). Ich sehe das als bloße Schikane.

Ok, offenbar verstehen wir unter der Strict-Aliasing-Rule was anderes!? Ich verstehe drunter die Regel, die besagt, dass es UB ist, auf das stored value eines Objektes über etwas anderes als ein dem dynamischen Typ des Objektes entsprechendes glvalue oder ein glvalue vom Typ char oder unsigned char zuzugreifen (die restlichen Ausnahmen seien hier mal egal).

dot hat geschrieben:Wie gesagt: memcpy() in ein char Array ist die einzige, mir bekannte Vorgehensweise, die vermutlich eher kein UB als UB ist.

Krishty hat geschrieben:

dot hat geschrieben:Wie gesagt: memcpy() in ein char Array ist die einzige, mir bekannte Vorgehensweise, die vermutlich eher kein UB als UB ist.

Richtig. Seit ein paar Jahren könnten Compiler auch clever genug sein, das zu optimalem Code zu optimieren (cbloom hat da was erwähnt – 11-14-15 | Copying words). Wenn du's ausprobierst, poste bitte mal das Disassembly mit VC 2015 und GCC.

#include <new>
#include <cstring>

unsigned int float_as_int(float f)
{
  unsigned char b[4];
  //unsigned int x;

  std::memcpy(&b, &f, sizeof(b));
  //std::memcpy(&x, &f, sizeof(x));
  //new (b) float(f);

  return (b[0] << 0) | (b[1] << 8) | (b[2] << 16) | (b[3] << 24);
  //return x;
}

int main()
{
  return float_as_int(42.0f);
}

((b[0] << 0) & 0xFF) | ((b[1] << 8) & 0xFF) | ((b[2] << 16) & 0xFF) | ((b[3] << 24) & 0xFF)

Krishty hat geschrieben:Der Beispielcode ist für den umgekehrten Fall, float zu int. Wie würde int zu float aussehen? Danach können wir zu den einzelnen Anweisungen kommen :)

dot hat geschrieben:imo einigermaßen standardkonform

Alexander Kornrumpf hat geschrieben:

dot hat geschrieben:imo einigermaßen standardkonform

Nur mal so aus Neugier, es muss doch einen bekannten standardkonformen, schlimmstenfalls langsamen Weg geben, an die Bits von beliebigem zu kommen. Im Zweifelsfall über einen Stream?!

dot hat geschrieben:

Alexander Kornrumpf hat geschrieben:

dot hat geschrieben:imo einigermaßen standardkonform

Nur mal so aus Neugier, es muss doch einen bekannten standardkonformen, schlimmstenfalls langsamen Weg geben, an die Bits von beliebigem zu kommen. Im Zweifelsfall über einen Stream?!

Kopieren per std::memcpy() in ein char Array ist der einzige, mir bekannte, arguably wirklich standardkonforme Weg (und der funktioniert nur, so lange es sich um einen trivially-copyable Type handelt).

Biolunar hat geschrieben:

dot hat geschrieben:

Alexander Kornrumpf hat geschrieben:

dot hat geschrieben:imo einigermaßen standardkonform

Nur mal so aus Neugier, es muss doch einen bekannten standardkonformen, schlimmstenfalls langsamen Weg geben, an die Bits von beliebigem zu kommen. Im Zweifelsfall über einen Stream?!

Kopieren per std::memcpy() in ein char Array ist der einzige, mir bekannte, arguably wirklich standardkonforme Weg (und der funktioniert nur, so lange es sich um einen trivially-copyable Type handelt).

In C99 und C11 ist das Konvertieren per union ebenfalls standardkonform (in C89 nicht!). Im Standard steht auch was von Zugriff über einen „character type“, ich nehme daher an, dass der Zugriff über char, signed char und unsigned char Pointer wohldefiniert ist.

Krishty hat geschrieben:Mach noch ein static_assert() mit alignof!

dot hat geschrieben:

Krishty hat geschrieben:Mach noch ein static_assert() mit alignof!

Sollte imo nicht nötig sein, da wir ja kopieren... ;)