Garantiert mir der Standard, dass in einem Struct, welches ausschließlich char member und char array members besitzt, alle wirklich hintereinander im speicher liegen oder kann da auch irgendein alignment dazwischenpfuschen?

struct Foo
{
    char bar1;
    char bar[2];
}

Vermutl. findet am Schluss zusätzlich irgendeine Form von Padding statt?

Grüße

PS: Kontext: Schreiben/lesen einer Binärdatei

Diese Frage hat meist Faulheit als Hintergrund.

Nö, der Hintergrund ist bessere Code-Les- und Wartbarkeit. (Aber natürlich nur, wenn das Vorgehen laut Standard OK sein sollte.)

knivil schrieb:

Warum machst du dich nicht gleich unabhaengig von Padding? Auch kannst du leicht mittels sizeof pruefen, ob Padding oder nicht.

Das ist mir schon klar. Mir gehts in erster Linie ja auch um das alignment innerhalb des structs.

PS: Kontext: Schreiben/lesen einer Binärdatei

So als Tip: Lesen und schreiben von strukturierten Daten implementiert man am Besten elementweise. Dann hat man solche Probleme nicht.

Hallo!

Garantiert mir der Standard, dass in einem Struct, welches ausschließlich char member und char array members besitzt, alle wirklich hintereinander im speicher liegen oder kann da auch irgendein alignment dazwischenpfuschen?

struct Foo
{
    char bar1;
    char bar[2];
}

Vermutl. findet am Schluss zusätzlich irgendeine Form von Padding statt?

Grüße

PS: Kontext: Schreiben/lesen einer Binärdatei

Für C++98 wird hier wahrscheinlich nichts garantiert.
Mit C++11 kann man die Frage anders formulieren:

struct Foo { char bar1; char bar[2]; };
struct Foo2 { char bar[3]; };

Sind Foo und Foo2 layout-kompatibel?
Leider findet sich keine explizite Aussage zu Arrays. Wir wissen zwar genau, wie ein Array aufgebaut ist, unklar bleibt aber, ob wir dieses Wissen bei Klassen anwenden können.

3.9/11
If two types T1 and T2 are the same type, then T1 and T2 are layout-compatible types. [ Note: Layoutcompatible enumerations are described in 7.2. Layout-compatible standard-layout structs and standardlayout
unions are described in 9.2. —end note ]

9.2/17
Two standard-layout struct (Clause 9) types are layout-compatible if they have the same number of non-static data members and corresponding non-static data members (in declaration order) have layout-compatible types (3.9).

Die Frage ist hier, ob mit "corresponding non-static data members" auch ganze Arrays gemeint sind, oder ob vielmehr auf die einzelnen Elemente des Arrays abgestellt wird.

9/11
Nonstatic data members of a (non-union) class with the same access control (Clause 11) are allocated so that later members have higher addresses within a class object. The order of allocation of non-static data members with different access control is unspecified (11). Implementation alignment requirements might cause two adjacent members not to be allocated immediately after each other; so might requirements for space for managing virtual functions (10.3) and virtual base classes (10.1).

Diese Aufzählung scheint vollständig zu sein: Standardlayout-Klassen haben keine virtuellen Funktionen oder Basen, und zischen zwei aufeinander folgenden chars ist niemals padding erforderlich, um korrektes Alignment herzustellen. Ich tendiere deshalb dazu, dass der neue Standard ausreichende Garantien gibt. Allerdings lässt die Formulierung durchaus Spielraum für andere Interpretationen.

So als Tip: Lesen und schreiben von strukturierten Daten implementiert man am Besten elementweise. Dann hat man solche Probleme nicht.

Nein, das kann doch keiner lesen oder gar verstehen.

Tachyon schrieb:

So als Tip: Lesen und schreiben von strukturierten Daten implementiert man am Besten elementweise. Dann hat man solche Probleme nicht.

Nein, das kann doch keiner lesen oder gar verstehen.

Und die Lösung wäre dann?

knivil schrieb:

Tachyon schrieb:

So als Tip: Lesen und schreiben von strukturierten Daten implementiert man am Besten elementweise. Dann hat man solche Probleme nicht.

Nein, das kann doch keiner lesen oder gar verstehen.

Und die Lösung wäre dann?

Ironie verstehen.