Padding bei Klassen die ausschliesslich aus build-in Typen bestehen

hustbaer

dot schrieb:

hustbaer schrieb:

(Ich denke jetzt z.B. an einen reinterpret_cast<POINT*>(&rect) und ähnliche Dinge -- die in Windows-Programmen nichtmal so selten anzutreffen sind.)

Witzigerweise ist genau das eines der Beispiele, die dank dem nun eingeführten Standard Layout Kram nun legal sind...

Echt?
Und das trotz

typedef struct _RECT {
  LONG left;
  LONG top;
  LONG right;
  LONG bottom;
} RECT, *PRECT;

typedef struct tagPOINT {
  LONG x;
  LONG y;
} POINT, *PPOINT;

Wie verträgt sich das dann mit Strict Aliasing? Wurde die Regel entsprechend aufgeweicht oder ...?

Wenn das RECT natürlich als POINT topleft; POINT bottomRight; definiert wäre, dann gäbe es kein Problem. Dann wäre es einfach ein "inner pointer", und die sind ja schliesslich ~~nicht~~ erlaubt. Und neue legale Wege zu schaffen wie man so einen "inner pointer" erzeugen kann... OK, das ist ja nicht SO ein Ding.

@Furble Wurble
Siehe oben.

hustbaer

volkard schrieb:

hustbaer schrieb:

(Ich denke jetzt z.B. an einen reinterpret_cast<POINT*>(&rect) und ähnliche Dinge -- die in Windows-Programmen nichtmal so selten anzutreffen sind.)

Hihi, ja, Faulheit siegt halt.

RECT rect = ...
HWND hwnd = ...
::ClientToScreen(hwnd, reinterpret_cast<POINT*>(&rect));
::ClientToScreen(hwnd, reinterpret_cast<POINT*>(&rect) + 1);

Würde ich heute nimmer schreiben, aber schon oft gesehen.
Und wenn ich den 2. Aufruf nicht bräuchte, sondern aus irgend einem Grund nur "top-left" ändern will, dann ... muss ich ehrlich sagen, könnte es auch heute noch passieren dass ich das schreibe.

dot

hustbaer schrieb:

dot schrieb:

hustbaer schrieb:

(Ich denke jetzt z.B. an einen reinterpret_cast<POINT*>(&rect) und ähnliche Dinge -- die in Windows-Programmen nichtmal so selten anzutreffen sind.)

Witzigerweise ist genau das eines der Beispiele, die dank dem nun eingeführten Standard Layout Kram nun legal sind...

Echt?

Ok, da war ich etwas zu vorschnell. Mit reinem Pointercast allein geht das nicht, man braucht doch eine union (nur so ist garantiert, dass beide Objekte passend aligned sind):

union
{
  RECT r;
  POINT p;
} stuff;

stuff.r.left = 42;
if (p.x)
  ; // wohldefiniert

hustbaer schrieb:

dot schrieb:

hustbaer schrieb:

(Ich denke jetzt z.B. an einen reinterpret_cast<POINT*>(&rect) und ähnliche Dinge -- die in Windows-Programmen nichtmal so selten anzutreffen sind.)

Witzigerweise ist genau das eines der Beispiele, die dank dem nun eingeführten Standard Layout Kram nun legal sind...

Echt?
Und das trotz
typedef struct _RECT {
  LONG left;
  LONG top;
  LONG right;
  LONG bottom;
} RECT, *PRECT;

typedef struct tagPOINT {
  LONG x;
  LONG y;
} POINT, *PPOINT;
[...]
Wenn das RECT natürlich als POINT topleft; POINT bottomRight; definiert wäre, dann gäbe es kein Problem. Dann wäre es einfach ein "inner pointer", und die sind ja schliesslich nicht erlaubt.

Wieso "nicht erlaubt"? Das ist doch genau mein Beispiel - und durchaus erlaubt.

hustbaer

@Furble Wurble
Oops.
Das "nicht" ist zu viel. Ich glaub ich wollte "nicht verboten" schreiben, und hab dann zu später auf "erlaubt" umformuliert.