std::start_lifetime_as : legales aliasing auf das alle gewartet haben?

Was sind denn diese "aliasing-Probleme", die das Konstrukt löst? Bisher wurde da halt wild gecastet, insofern sieht das jetzt schöner aus, aber funktional ändert sich doch nichts, oder?

Klaus schrieb:

Was sind denn diese "aliasing-Probleme", die das Konstrukt löst

https://stackoverflow.com/a/99010/4730685

Niklas G. schrieb:

Klaus schrieb:

Was sind denn diese "aliasing-Probleme", die das Konstrukt löst

https://stackoverflow.com/a/99010/4730685

Genau das dort geschilderte Problem löst das aber doch auch nicht. Wenn im stream von aussen Daten mit inkompatiblen Aliasing reinkommen, dann ist das Aliasing inkompatibel.

Oliver

Oliver S. schrieb:

inkompatiblen Aliasing

Was meinst du damit?

Niklas G. schrieb:

https://stackoverflow.com/a/99010/4730685

... ein ziemlich kaputter Stackoverflow-Eintrag.

Klaus schrieb:

Was sind denn diese "aliasing-Probleme"

In einem Satz:

The main thing the optimizer wants to know here is whether writes through one pointer might affect reads through other pointers or names.

https://langdev.stackexchange.com/questions/2998/what-optimizations-does-the-strict-aliasing-rule-facilitate

Der Zusammenhang zum Eingangspost erschließt sich mir auf Anhieb aber auch nicht. (weil gerade char* nicht betroffen sind)

Cplusminus schrieb:

GCC 14 kann es leider noch nicht >_>. Aber sobald dass in den Compilern ankommt, sollten doch alle Aliasing Probleme in C++ geklärt sein? Zusätzlich bekommt C++ ein weiteren Vorteil gegenüber C.

Wenn in buffer[0] so etwas, wie ein Opcode steht, dann müsstest Du wahrscheinlich &buffer[1] verwenden.

In dem von Dir verlinkten Artikel steht doch explizit:

The behavior is undefined if: ... or the region is not suitably aligned for the T.

Demnach, müsste &buffer[1] das Alignment von Foo und Bar haben. Ob dem so ist, hängt dann doch wohl ganz stark von der Implementierung von stream->read() ab.