(Wann) Ist das (nicht) UB ?

[NaNi (Gast)]

Guten Abend.
Ja, das ist schon die ganze Frage: (Wann) Ist das (nicht) UB ?
...eine der Methoden aufzurufen?

...Und unter welchen Umständen wird es trotzdem relativ gefahrlos 
gemacht?

...Und warum spricht -fsanitize=undefined nicht darauf an? Ich dachte, 
dazu sei das da!

template<typename T>
struct A{
  T e0;
  T e1;
  T e2;
  //...
};

template<typename T>
struct B{
  T e0;
  T e1;
  T e2;
  //...

  //Wann kann man dies aufrufen?
  T & operator[](int i){
    return (*reinterpret_cast<const T(*)[3]>(this))[i];
  }
  //Oder dies
  A<T> & asA(int i){
    return (*reinterpret_cast<A<T>*>(this));
  }
};

Danke schon mal.

MfG

[MaWin (Gast)]

Einen reinterpret_cast kann man grob gesagt immer dann gefahrlos machen, 
wenn das Objekt tatsächlich dem entspricht, in das man es hincastet.

Fast immer gibts aber bessere Wege als reinterpret_cast.

[NaNi (Gast)]

Und wie kommt man in dem Fall dann vorher an etwas, das nicht dem Objekt 
entspricht, ohne UB?

Zu dem Fall oben: Warum spricht -fsanitize=undefined nicht darauf an? 
Ich dachte,
dazu sei das da!
Man könnte evtl sagen, dass das was da ist, zufällig dem entspricht, was 
es sein soll. Kann man das Bsp dann so verändern, dass es nicht mehr 
geht?

[Rolf M. (rmagnus)]

NaNi schrieb:
> (Wann) Ist das (nicht) UB ?
> ...eine der Methoden aufzurufen?

Ich würde sagen, eine struct als Array umzuinterpretieren und dann per 
Index zuzugreifen ist immer UB. Die zweite Funktion ist soweit ich 
verstehe auch immer UB, da man mit dem Zeiger, der aus dem 
reintepret_cast rausfällt, nicht viel mehr machen darf, als ihn wieder 
in den ursprünglichen Typ zurückzucasten.
Wobei es lustigerweise erlaubt wäre, über eine union zu gehen, sofern T 
ein POD ist. Wenn eine union zwei structs enthält, die POD sind und 
gleich anfangen, dann ist es erlaubt, auf die entsprechenden Member auch 
über die "falsche" Struktur zuzugreifen.

[MaWin (Gast)]

NaNi schrieb:
> Warum spricht -fsanitize=undefined nicht darauf an?

Weil das natürlich nicht alle Arten von UB abfangen kann.

> Und wie kommt man in dem Fall dann vorher an etwas, das nicht dem Objekt
entspricht, ohne UB?

Hä?

[MaWin (Gast)]

Hast du einmal versucht das vernünftig mit einem switch zu 
implementieren?
Welcher Code wird daraus optimiert? Der Compiler sollte in der Lage sein 
zu erkennen, dass die Elemente in einer Reihe liegen und dann per 
pointer arithmetik zugreifen können (nach einer initialen 
Bereichsabfrage).

[NaNi (Gast)]

Rolf M. schrieb:
> Wobei es lustigerweise erlaubt wäre, über eine union zu gehen, sofern T
> ein POD ist. Wenn eine union zwei structs enthält, die POD sind und
> gleich anfangen, dann ist es erlaubt, auf die entsprechenden Member auch
> über die "falsche" Struktur zuzugreifen.

Moment, wie?! Soweit ich weiß, existiert immer nur ein Member eines 
Union gleichzeitig.
Wenn sie jetzt ein komplett, statt nur zu Beginn, identisches 
Datenlayout hätten, ok, aber was meinst du mit "gleich anfangen"? 
Padding z.B. gibts doch auch bei POD.

MaWin schrieb:
> Weil das natürlich nicht alle Arten von UB abfangen kann.

Weißt du, ob das die Bedründung ist? Ich meine, könnte sein, aber muss 
das der Grund sein? Es scheint Ausnahmen zu geben, dort, wo der Compiler 
mit Absicht nicht standardkonform (aber irgendwie noch ISO-xy-konform) 
ist.

MaWin schrieb:
> Hä?

Ah, schon gut. Denkfehler.

MaWin schrieb:
> Hast du einmal versucht das vernünftig mit einem switch zu
> implementieren?
> Welcher Code wird daraus optimiert? Der Compiler sollte in der Lage sein
> zu erkennen, dass die Elemente in einer Reihe liegen und dann per
> pointer arithmetik zugreifen können (nach einer initialen
> Bereichsabfrage).

Das wollte ich mir eigentlich ersparen. Wenn schon Array, dann auch mit 
theoretisch 50k Einträgen..

[MaWin (Gast)]

NaNi schrieb:
> Wenn schon Array, dann auch mit
> theoretisch 50k Einträgen..

Das kannst du ja machen. Aber dann solltest du es auch komplett 
durchziehen und auf das struct ganz verzichten.

[NaNi (Gast)]

MaWin schrieb:
> Das kannst du ja machen. Aber dann solltest du es auch komplett
> durchziehen und auf das struct ganz verzichten.

Nein.
Ich meinte damit, ich würde mich dabei weniger auf den Compiler 
verlassen.
"Sollte erkennen" == UB ...

[MaWin (Gast)]

NaNi schrieb:
> "Sollte erkennen" == UB ...

Unsinn.

[NaNi (Gast)]

MaWin schrieb:
> Unsinn.

Aber auf "Sollte erkennen" == Konjunktiv ... können wir uns einigen?

MaWin schrieb:
> Das kannst du ja machen. Aber dann solltest du es auch komplett
> durchziehen und auf das struct ganz verzichten.

Wozu dann noch:

MaWin schrieb:
> Hast du einmal versucht das vernünftig mit einem switch zu
> implementieren?

??

[MaWin (Gast)]

NaNi schrieb:
> Wozu dann noch:

Ja. Entweder, oder.

Jedenfalls ist keines davon UB. Im Gegensatz zu dem reinterpret_cast.

[Zombie (Gast)]

   T & operator[](int i){
     return (*reinterpret_cast<const T(*)[3]>(this))[i];
   }

ich glaube, das ist kein UB. Warum? Siehe hier:
https://en.cppreference.com/w/cpp/numeric/complex (siehe unter 
Array-oriented access)

Ich kann mir kaum vorstellen, dass für std::complex hier spezielle 
regeln gelten.

[Rolf M. (rmagnus)]

NaNi schrieb:
> Rolf M. schrieb:
>> Wobei es lustigerweise erlaubt wäre, über eine union zu gehen, sofern T
>> ein POD ist. Wenn eine union zwei structs enthält, die POD sind und
>> gleich anfangen, dann ist es erlaubt, auf die entsprechenden Member auch
>> über die "falsche" Struktur zuzugreifen.
>
> Moment, wie?! Soweit ich weiß, existiert immer nur ein Member eines
> Union gleichzeitig.

Im Grunde ja, aber es gibt die von mir beschriebene Ausnahme, die von C 
übernommen wurde. Hauptsächlich wohl, um in etwa so was zu ermöglichen:

enum event_type
{
    mouse_move, mouse_click
};

struct event
{
    event_type type;
};

struct move_event
{
    event_type type;
    int x, y;
};

struct click_event
{
    event_type type;
    int button;
};

union event_union
{
    event event;
    move_event move;
    click_event click;
};

void handle_event(const event_union* u)
{
    switch (u->event.type) // Zugriff über anderes Element
    {
        case mouse_move:
            // handle u.move
            break;
        case mouse_click:
            // handle u.click
            break;
}

> Wenn sie jetzt ein komplett, statt nur zu Beginn, identisches
> Datenlayout hätten, ok, aber was meinst du mit "gleich anfangen"?

Ich meine, dass die ersten paar Member in den Strukturen von Typen sind, 
die das gleiche Layout haben (in C++-Sprech "common initial sequence"). 
Dann hat auch der Teil der Strukturen das gleiche Layout (in C++-Sprech 
"layout-compatible"), und man darf auf genau diese auch über die andere 
Struktur zugreifen. Hier der Original-Text aus dem C++17-Draft:
"If a standard-layout union contains two or more standard-layout structs 
that share a common initial sequence, and if the standard-layout union 
object currently contains one of these standard-layout structs, it is 
permitted to inspect the common initial part of any of them. Two 
standard-layout structs share a common initial sequence if corresponding 
members have layout-compatible types and either neither member is a 
bit-field or
both are bit-fields with the same width for a sequence of one or more 
initial members."

> Padding z.B. gibts doch auch bei POD.

Ja, aber wenn die Member die gleichen sind, ist auch das Padding das 
gleiche.

[Wilhelm M. (wimalopaan)]

Als Lösung dafür gibt es std::bit_cast (ist auch constexpr).

[NaNi (Gast)]

Rolf M. schrieb:
> Im Grunde ja, aber es gibt die von mir beschriebene Ausnahme, die von C
> übernommen wurde. Hauptsächlich wohl, um in etwa so was zu ermöglichen:

Ah, ja. Jetzt verstehe ich was du meinst. Anscheinend gab es vor c11 
keine anonymen unions. Was diese Ausnahme vieleicht nötig gemacht hat.

Wilhelm M. schrieb:
> Als Lösung dafür gibt es std::bit_cast (ist auch constexpr).

Sieht so aus, als würde das aber immer eine Kopie zurück geben. Käme 
also nicht ganz an unions oder reinterpret_casts dran.

[Wilhelm M. (wimalopaan)]

NaNi schrieb:
> Rolf M. schrieb:
>> Im Grunde ja, aber es gibt die von mir beschriebene Ausnahme, die von C
>> übernommen wurde. Hauptsächlich wohl, um in etwa so was zu ermöglichen:
>
> Ah, ja. Jetzt verstehe ich was du meinst. Anscheinend gab es vor c11
> keine anonymen unions. Was diese Ausnahme vieleicht nötig gemacht hat.

Ich kenne zwar auch die o.g. Ausnahme mit der common-initial-sequence 
bei unions, aber trotzdem bleibt der Zugriff über das non-aktiv member, 
was UB ist. Zumindest scheint der g++ das so zu interpretieren.

Eine der besten Möglichkeiten herauszufinden, ob ein Konstrukt UB ist, 
es in einen constexpr-Kontext zu verfrachten (dazu hatte ich vor einiger 
Zeit (Jahren) mal Beispiele gemacht, die ich hier zwar auch gepostet 
hatte, nun aber gerade auf die Schnelle nicht wiederfinde). Denn in 
einem constexpr-Kontext ist kein UB erlaubt -> diagnostic required!

Daher gibt leider doch das obige Konstrukt (im g++) UB:

enum event_type {
    mouse_move, mouse_click
};
struct event {
    event_type type;
};
struct move_event {
    event_type type;
    int x, y;
};
struct click_event {
    event_type type;
    int button;
};
union event_union {
    event e;
    move_event move;
    click_event click;
};

constexpr int handle_event(const event_union* u) {
    switch (u->e.type) // Zugriff über anderes Element
    {
        case mouse_move:
            // handle u.move
            break;
        case mouse_click:
            // handle u.click
            break;
    }
    return 0;
}
int main() {
    constexpr event_union e {.click = {event_type::mouse_click, 1}};
    constexpr auto r = handle_event(&e); // <---- Fehler

Angeqendet auf das Beispiel des TO:

template<typename T>
union AB {
    A<T> a;
    B<T> b;
};

template<typename T>
constexpr char test() {
    AB<T> ab;
    ab.a.e0 = 1; 
    return ab.b.e0; // <--- UB wegen non-active member
}

> Wilhelm M. schrieb:
>> Als Lösung dafür gibt es std::bit_cast (ist auch constexpr).
>
> Sieht so aus, als würde das aber immer eine Kopie zurück geben. Käme
> also nicht ganz an unions oder reinterpret_casts dran.

Ich denke, das std::bit_cast hier (meistens) auf die Kopie verzichten 
wird, weil es eben genau für diesen Anwendungsfall (als built-in) 
gemacht worden ist. Das erkennen des punning-patterns ist genau seine 
Aufgabe. Im Gegensatz zu memcpy(), was das zwar auch (oft) erkennt, aber 
dann eben auch nicht constexpr ist.

Wie man oben sieht, betrachtet der g++ den Weg über unions (trotz der 
Ausnahme im C++-Standard) als UB, und das reinterpret_cast sowieso (was 
zudem auch nicht in einem constexpr-Kontext angewendet werden kann).

[Wilhelm M. (wimalopaan)]

Leider kann ich den obigen Beitrag nicht löschen ...
Edieren kann ich ihn auch nicht mehr.

Er ist falsch, bitte nicht beachten.

[Wilhelm M. (wimalopaan)]

Wenn Du homogene Datenelemente in den Klassen hast, kannst ggf. ein 
Array nehmen. Wenn Du weiterhin eine Basistemplate einführst, dann 
erhälst Du folgendes:

#include <cstdint>
#include <array>

template<typename T, size_t N>
struct Base {
    std::array<T, N> e;
    const T& operator[](size_t i) const {
        return e[i];
    }
};
template<typename T>
struct A : Base<T, 3> {    
};

template<typename T>
struct B : Base<T, 3> {   
};
int main() {
    const A<char> a{1, 2, 3};
    const B<char> b{4, 5, 6};
    
    return a[0] + b[0];
}

Vielleicht das Deine Anforderungen?