jetzt habe ich hier ein dummes Problem. In meiner Geometrie-Lib, hatte ich Rechtecke gewollt, wo ich sowohl direkten Zugriff auf die elementaren Koordinaten bzw. Größen hatte, wie auch auf den Ursprungspunkt und die kombininierte Größe.

Also so (ohne templates jetzt):

struct BSize {
   int SX,SY;
};

struct Size : public BSize
{
//...
};

struct BPoint {
    int X,Y;
};

struct Point : public BPoint
{
//...
};

struct Rect {
//...

    union {
       struct { int X, int Y };
       BPoint P;
    };

    union {
       struct { int SX, int SY };
       BSize S;
    };
};

So, das funktioniert auch alles toll, bis man auf die Idee kommt, dass man gerne Konstante Punkte und Größen definieren/erzeugen möchte. Dann bräuchte man auf einmal einen Konstruktor in BSize/BPoint und damit sind sie nicht mehr dafür gut, als Element in dem Union zu dienen.

Fällt euch eine Abhilfe ein? Eigentlich möchte ich nur einfachen Zugriff auf X, Y, SX, SY sowie den zusammengesetzten P und S haben, aber mir ist C++ hier im Weg -.-.

Viele Grüße,
Deci

P.S.: Der Sinn und Zweck einer Union ist eigentlich Speichersparen. Was heutzutage sicherlich eher selten vorkommen sollte. Der übliche Hack mit unions wird auf den meisten Systemen ebenfalls funktionieren, zumindest mit PODs. Mache (alle?) Compiler garantieren sogar, dass es funktioniert. Ich würde es in C++ aber trotzdem nicht benutzen, denn üblicherweise schadest du dir selber, wenn du das Typensystem aushebelst.

struct Rect {
	struct { int X, int Y };
	BPoint getP() { return *reinterpret_cast<BPoint*>(&X);}

	struct { int SX, int SY };
	BSize getP() { return *reinterpret_cast<BSize*>(&SX);}
};

So in der Richtung. Ich meine, Membervariablen liegen direkt hintereinander im Speicher. Das heisst, wenn du per "Array" auf X zugreifst, dann wäre X[0] X selbst und X[1] wäre Y.

Valve macht das so bei einer Klasse für Farben in der Source Engine.
Etwa so, falls ich das richtig im Kopf habe

class Colo
{
	byte r, g, b, a;

	int getColor()
	{
		return *(reinterpret_cast<int*>(&r));
	}
};

Die Vor-/Nachteile und Stolperfallen kannst du dir ja denken.

Point p1 = r.O;
   Point p2 /* = irgendwas */;

   r.S = p2 - p1;
   r.S() = p2 - p1; // wie hässlich ist das denn bitte?

Jetzt könnte ich natürlich Getter und Setter dahinfriemeln, die eben ein Size<TX&,TY&>-Proxy zurückgeben (das dann bitte bitte direkt vom Compiler wieder geschluckt wird), aber dann schreibe ich im User-Code überall Klammern, wo ich in den Ausdrücken keine Klammern sehen will, weil sie mir die mathematischen Formeln zumüllen. Hätte C++ Properties, wäre das ja alles kein Problem -.-.

r.S.SX = foo;

Da mag ich den "tradeoff"

r.S() = foo;
   r.SX  = bar;

lieber.
Irgendwie wäre ein Konstrukt wie

struct Bla {
  struct { int a; } Blubb;
  using b = Blubb.a;
};

toll