class MyClass
{
public:
 uint* getMembers();
private:
 uint a;
 uint b;
 uint c;
}

Ich möchte nun eine Funktion schreiben, die a, b und c zurückgibt. Kann ich diese so

uint* getMembers()
{
 return a&;
}

realisieren, sodass bei

uint* data = obj.getMembers();

data[0] == a; data[1] == b und data[2] == c

Oder anders gefragt: Kann C++ garantieren, dass selbst bei eingeschalteter Optimierung die Member in genau dieser Reihenfolge im Speicher vorkommen und dass auf die eine primitive Membervariable direkt die andere folgt?

Falls das nicht funktioniert, gibt es soetwas wie std::auto_ptr für arrays, sodass z.B.

auto_array_ptr<uint> getMembers()
{
  uint array[] = new uint[3];
  array[0] = a;
  array[1] = b;
  array[2] = c;
  return auto_array_ptr<uint>(array);
}

Es müsste eben sichergestellt werden, dass das dynamisch allozierte Array nach dem Austritt aus dem Scope gelöscht wird.

MfG, Golem

Oder anders gefragt: Kann C++ garantieren, dass selbst bei eingeschalteter Optimierung die Member in genau dieser Reihenfolge im Speicher vorkommen und dass auf die eine primitive Membervariable direkt die andere folgt?

Es wird vom C++-Standard garantiert, dass die Reihenfolge von Membern unter dem gleichen Zugriffsspezifizierer der Deklaration entspricht. Aber bezüglich Alignment können Optimierungen Probleme bereiten. Normalerweise verlässt man sich aber auch nicht auf die Ausrichtung innerhalb der Klasse, da man über den Variablennamen zugreift. Vielleicht bringt dir jedoch offsetof etwas.

Golem86 schrieb:

Falls das nicht funktioniert, gibt es soetwas wie std::auto_ptr für arrays [...] Es müsste eben sichergestellt werden, dass das dynamisch allozierte Array nach dem Austritt aus dem Scope gelöscht wird.

Es gäbe zwar boost::shared_array bzw. boost::scoped_array .

Aber das scheint mir der falsche Ansatz zu sein. Warum benötigst du gleich alle drei Membervariablen auf einmal? Wäre es nicht sinnvoller, die auch in einem Array zu speichern?

Sonst - was mir die beste Möglichkeit scheint - könntest du auch std::tr1::array ( boost::array ) oder STL-Container zurückgeben, dann müsstest du dich nicht um den Speicher kümmern.

Es müsste eben sichergestellt werden, dass das dynamisch allozierte Array nach dem Austritt aus dem Scope gelöscht wird.

Was spricht gegen einen std::vector?
Mal davon abgesehen dass du eh so gut wie nie diekten Zugriff auf member geben solltest. Das riecht ziemlich arg nach einem Designfehler.