Reihenfolge im struct und Reihenfolge im Speicher

[Struktur (Gast)]

Hallo,

wie ich schon leidlich erfahren musste liegen die struct-Einträge nicht 
immer lückenlos nebeneinander, sondern es kann sein, dass der 
Prozessorarchitektur geschuldet nach einem boolschen Wert durchaus ein 
Freiraum entstehen kann, bevor der nächste Eintrag mit beispielsweise 
uint16_t gefunden wird.


Nun aber noch eine weitere Frage, gegeben ist folgendes struct:

typedef struct
{
  char Eintrag1[30];
  char Eintrag2 [50];
  char eintrag3 [20];
}MEINSTRCUT;

Liegt der Eintrag2 zwingend hinter dem Eintrag1 im Speicher?

[Ver Wirrter (Gast)]

Warum ist hinter <Eintrag1> kein Blank, aber hinter
<Eintrag2> und <Eintrag3> schon?

Hat das einen tieferen Sinn?

[Ver Wirrter (Gast)]

Typdefinitionen tut man nicht grossschreiben tun.
Das tut man nur bei Defines und Konstanten.
Tut man so! Isso bei anständigen Programmierern.

Ja gut, C ist geduldig, machen kann man alles.

[Axel S. (a-za-z0-9)]

Struktur schrieb:
>

> typedef struct
> {
>   char Eintrag1[30];
>   char Eintrag2 [50];
>   char eintrag3 [20];
> }MEINSTRCUT;
>

>
>
> Liegt der Eintrag2 zwingend hinter dem Eintrag1 im Speicher?

Das hättest du mit minimalem Aufwand selber herausfinden können:

https://www.google.de/search?q=c+struct+memory+layout

gleich der erste Treffer beantwortet deine Frage:

https://stackoverflow.com/questions/2748995/c-struct-memory-layout

[M.A. S. (mse2)]

Vielleicht auch interessant (bin gerade, angeregt durch diesen Thread, 
darauf gestossen, hab's aber noch nicht gelesen):

http://www.catb.org/esr/structure-packing/

[Dr. Sommer (Gast)]

Struktur schrieb:
> nach einem boolschen Wert durchaus ein Freiraum entstehen kann, bevor
> der nächste Eintrag mit beispielsweise uint16_t gefunden wird.
>
> Nun aber noch eine weitere Frage, gegeben

Nicht nur nach bool Werten, sondern nach allen Datentypen. Die 
Reihenfolge ist aber so wie im Code vorgegeben.
Wozu ist das wichtig? Möchtest du den struct über eine Schnittstelle 
verschicken oder in eine Datei speichern und dabei ein bestimmtes Format 
erreichen (ohne Lücken)? Dann lies mal Serialisierung.

[Curby23523 N. (Gast)]

Du kannst ein struct mit dem Attribut PACKED versehen (googlen für 
korrekte Anwendung). Dann werden die Variablen genauso im Speicher 
angelegt, wie du sie angibst, in genau der Reihenfolge ohne irgendwelche 
Lücken.

[Frank M. (ukw) (Moderator)]

Curby23523 N. schrieb:
> Dann werden die variablen genazuso angelegt, wie du sie angibst, in
> genau der Reihenfolge ohne irgendwelche Lücken.

... unter Erkaufen eventueller drastischer Leistungseinbußen. Sollte man 
fairerweise erwähnen ;-)

[Dr. Sommer (Gast)]

Curby23523 N. schrieb:
> Du kannst ein struct mit dem Attribut PACKED versehen

Dann werden aber u.U. alle Zugriffe auf die Variablen langsam, und wenn 
es tatsächlich um das Speichern/Verschicken geht löst das die diversen 
anderen Probleme nicht (Byte Order, Sign Format, Strict Aliasing)

[Curby23523 N. (Gast)]

Danach hat der TO aber nicht gefragt. Mit "__attribute__((_packed_))" 
liegen die Variablen schön hintereinander.

[Dr. Sommer (Gast)]

Curby23523 N. schrieb:
> Danach hat der TO aber nicht gefragt.

Wenn man jemandem ein Vorgehen empfiehlt, darf man ihn schon über die 
Probleme aufklären. Und das "packed" Attribut ist nur ein Trostpflaster 
auf einem vermutlich unangemessenen Vorgehen.

[Frank M. (ukw) (Moderator)]

Naja, man kann auch ein Symptom behandeln statt die Ursache. Und diese 
liegt höchstwahrscheinlich im Code des TOs begraben.

Frage an den TO: Warum soll das Programm von der Reihenfolge 
irgendwelcher Variablen im Speicher abhängig sein?

Ich sehe eigentlich keine Voraussetzung für so eine gravierende 
Bedingung.

[Rufus Τ. F. (rufus)]

Es dauert keine fünf Minuten, das mit einem simplen C-Compiler zu 
untersuchen:

#include <stdio.h>

typedef struct
{
  char Eintrag1[30];
  char Eintrag2 [50];
  char eintrag3 [20];
}MEINSTRCUT;

int main()
{
    MEINSTRCUT bla;
 
    printf("bla      %p\n", &bla);

    printf("Eintrag1 %p\n", &bla.Eintrag1);
    printf("Eintrag2 %p\n", &bla.Eintrag2);
    printf("eintrag3 %p\n", &bla.eintrag3);

    return 0;
}

Ergebnis laut https://www.onlinegdb.com/online_c_compiler

bla      0x7ffd68e65fc0                                                                                                      
Eintrag1 0x7ffd68e65fc0                                                                                                      
Eintrag2 0x7ffd68e65fde                                                                                                      
eintrag3 0x7ffd68e66010

Warum traut sich heutzutage niemand mehr, Vermutungen einfach 
auszuprobieren?

[Dr. Sommer (Gast)]

Rufus Τ. F. schrieb:
> Warum traut sich heutzutage niemand mehr, Vermutungen einfach
> auszuprobieren?

Nur weil in C(++) etwas bei einem Versuch funktioniert, heißt das noch 
lange nicht dass es korrekt im Sinne des Standards ist, und daher unter 
allen Bedingungen funktioniert. Gerade solche Dinge wie Speicher-Layouts 
sind da ein gefährliches Pflaster.

[Halb Blinder (Gast)]

Rufus Τ. F. schrieb:
> Warum traut sich heutzutage niemand mehr, Vermutungen einfach
> auszuprobieren?

Die Ergebnisse eines Compilers (oder auch mehrerer) reicht
ja nicht aus um eine allgemein gültige Aussage zu liefern.

Erst wenn man alle Compiler auf der Welt danach ausgetestet hätte ....

[Rufus Τ. F. (rufus)]

Ich bin mir nicht sicher, ob der Threadstarter eine allgemeingültige 
Aussage, die für alle Compiler, Prozessorarchitekturen und Wetterlagen 
dieses Universums gilt, oder ob er vielleicht auch nur eine vage 
Vorstellung davon gewinnen möchte, wie Objekte im Speicher angeordnet 
werden.

Struktur schrieb:
> Liegt der Eintrag2 zwingend hinter dem Eintrag1 im Speicher?

Diese Frage kann sich nämlich auch auf die Reihenfolge beziehen. Ginge 
es nur ums Alignment, hätte die Frage anders gelautet, denn der 
Threadstarter hat durchaus verstanden, daß es eine entsprechende 
Ausrichtung von Strukturelementen geben kann.

[Frank M. (ukw) (Moderator)]

Rufus Τ. F. schrieb:
> Diese Frage kann sich nämlich auch auf die Reihenfolge beziehen.

Ich abe es auch so verstanden, dass die Frage ausschließlich die 
Reihenfolge betraf. Der TO schrieb auch im Eingangsbeitrag:

"dass der Prozessorarchitektur geschuldet nach einem boolschen Wert 
durchaus ein Freiraum entstehen kann, bevor der nächste Eintrag mit 
beispielsweise uint16_t gefunden wird."

Über die Lücken wusste er also Bescheid.

Und wenn er Google nach "C struct order" angeworfen hätte, dann hätte 
ihm bereits der erste Eintrag geholfen:

https://stackoverflow.com/questions/2748995/c-struct-memory-layout?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

--------------------
C99 §6.7.2.1:

12 Each non-bit-field member of a structure or union object is aligned 
in an implementation- defined manner appropriate to its type.

13 Within a structure object, the non-bit-field members and the units in 
which bit-fields reside have addresses that increase in the order in 
which they are declared. A pointer to a structure object, suitably 
converted, points to its initial member (or if that member is a 
bit-field, then to the unit in which it resides), and vice versa. There 
may be unnamed padding within a structure object, but not at its 
beginning.
--------------------

Die Reihenfolge ist in C also garantiert - abweichend zu anderen 
Programmiersprachen wie z.B. C#.

Ich selbst würde aber niemals Annahmen über Positionen in einer struct 
machen, denn es gibt immer eine portable Lösung.

[Sebastian S. (amateur)]

Ich weiß gar nicht ob das heute überhaupt noch nötig ist. Soweit mir 
bekannt packen die Compiler die Daten in der - für den Rechner - 
"natürlichen" Anordnung.
Hat man also einen 16 Bit Rechner, so werden, falls möglich, 
char-Variablen immer an Wort-Grenzen abgelegt. So ist der Zugriff zwar 
schneller, aber die Speicherausnutzung schlechter. Seit dem es dieses 
Verhalten gibt, gibt es auch das Schlüsselwort "packed".

[Dr. Sommer (Gast)]

Sebastian S. schrieb:
> Hat man also einen 16 Bit Rechner, so werden, falls möglich,
> char-Variablen immer an Wort-Grenzen abgelegt.
Bei char-Variablen eben nicht, aber alles was >= 2 Byte groß ist.

Sebastian S. schrieb:
> Seit dem es dieses
> Verhalten gibt, gibt es auch das Schlüsselwort "packed".
Das ist GCC-Spezifisch und nicht portabel...

[dummschwaetzer (Gast)]

Sollte in der Manual des Compilers für die jeweilige Zielplattform 
erwähnt sein.

[dummschwaetzer (Gast)]

z.B. MSP CodeCoposer 16.9 Kapitel 6.2.1 Data Type Storage

struct

Members are stored as their individual types require.

Multiple of 8 bits aligned to boundary of largest member type; members 
are stored and aligned as their individual types require.