Forum: Mikrocontroller und Digitale Elektronik Datenstrukture in C


von tenner (Gast)


Lesenswert?

hallo,
nehmen wir an ich erstelle eine struktur

typedef struct _MYSTRUCT {
  int iData;
  int iCounter;
  int iSize;
} MYSTRUCT, *PMYSTRUCT;

nun definiere ich

MYSTRUCT stMystruct;
PMYSTRUCT pstMystruct = &stMystruct;

kann ich nun davon ausgehen das die daten der struktur linear im
speicher liegen, so dass ich folgendermaßen darauf zugreifen kann?

iDataFromStruct = &((int*)pstMystruct);   // iDataFromStruct =
pstMystruct->iData
iCounterFromStruct = &((int*)pstMystruct+1));   // iCounterFromStruct =
pstMystruct->iCounter
iSizeFromStruct = &((int*)pstMystruct+2));   // iSizeFromStruct =
pstMystruct->iSize

gruß tenner

von miwitt001 (Gast)


Lesenswert?

Womit compilierst du denn?? Ich weiß nur, dass es im MS Visual Studio
geht, da hab ich es selber schonmal gemacht.

mfg

von tenner (Gast)


Lesenswert?

mich interessiert eigentlich ob dem generell so ist. sollte es mit dem
einen compiler gehen und dem anderen nicht, muß ich mir eh was anderes
überlegen.
ich nutze zumeist den gcc.

von Rolf Magnus (Gast)


Lesenswert?

Es hängt nicht nur vom Compiler, sondern auch von der
Hardware-Architektur ab.

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Du kannst nicht unbedingt davon ausgehen, daß die Strukturelemente ohne
"Füllstoff" linear aufeinanderfolgend im Speicher liegen.
Bei Deinem Beispiel wird das zwar der Fall sein, aber wenn auch nur ein
Element anderer Strukturgröße dazwischenliegt, dann besteht die reelle
Chance, daß nachfolgende Strukturelemente neu ausgerichtet werden.

Ein Beispiel, angenommen sei sizeof (int) == 4:

struct bla
{
  int wert1;   // offset 0
  char wert2;  // offset 4
  int wert3;   // offset 8
};

Diese Ausrichtung ist bei einigen Prozessorarchitekturen zwingend
erforderlich; nicht jeder Prozessor kann 32-Bit-Zugriffe auf nicht
durch vier teilbare Adressen ausführen. Manche Prozessorarchitekturen
haben dieses Problem bereits bei 16-Bit-Zugriffen, wie beispielsweise
68K.

Mit
  #pragma pack(1)
kann der C-Compiler allerdings davon überzeugt werden, Strukturelemente
ohne "Füllbytes" auszurichten; der Compiler wird, sofern es
erforderlich ist, aufwendigeren Code für "misaligned" 32-Bit-Zugriffe
erzeugen.

Die x86-Architektur lässt hingegen beliebige 32-Bit-Zugriffe zu; der
Prozessor teilt einen "misaligned" Zugriff auf zwei nacheinander
folgende Zugriffe auf und schiebt sich die Daten zurecht. Das ist
natürlich langsamer als ein "aligned" Zugriff ... daher empfiehlt es
sich aus Performancegründen auch auf x86 mit #pragma pack(4)
(Standardvorgabe) zu arbeiten.

Also:

Wenn Du vor Deine Strukturdeklaration das #pragma pack setzt, dann
kannst Du davon ausgehen, daß die Daten tatsächlich so im Speicher
angeordnet sind, wie von Dir vorgesehen.

Ein einfacher Test wäre ein Vergleich der Speichergrößen:

Struktur mit #pragma pack(4) deklarieren, sizeof (struktur) ausgeben,
dasselbe mit pack(1) und Ergebnisse vergleichen.

von Rolf Magnus (Gast)


Lesenswert?

> Mit
>   #pragma pack(1)
> kann der C-Compiler allerdings davon überzeugt werden,

Wobei "Der C-Compiler" in diesem Fall der von Microsoft ist. Einige
andere haben das aber aus Kompatibilitätsgründen übernommen.

von tenner (Gast)


Lesenswert?

@Rufus vielen dank für die hilfe, dass war genau das was ich wissen
wollte.

gruß tenner

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.