mikrocontroller.net

Forum: Compiler & IDEs C: Überkreuzabhängigkeiten structs in Headerfiles


Autor: Bahara (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

stehe ich gerade vor einem "Henne-Ei-Problem"!

Habe zwei Headerfiles in denen jeweils eine Struktur definiert wird.
Das doofe: Die Struktur aus Headerfile A beinhaltet die in Headerfile B 
definierte Struktur und umgekehrt.

File a.h:
#ifndef a_h_
#define a_h_

#include "b.h"

typedef struct 
{
  uint8 x;
  uint8 y;
  MyStructB z;
} MyStructA;

#endif /* a_h_ */

File b.h:
#ifndef b_h_
#define b_h_

#include "a.h"

typedef struct 
{
  uint8 af;
  uint8 fe;
  MyStructA be;
  MyStructA af;
} MyStructB;

#endif /* b_h_ */

Wie bekomme ich dieses Dilemma gelöst?

Besten Dank und viele Grüße
Bahara

Autor: Jörg W. (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
5 lesenswert
nicht lesenswert
Bahara schrieb:
> Wie bekomme ich dieses Dilemma gelöst?

Erstens dürfen structs einen Namen im struct-Namensraum bekommen:
struct foo {
  ...
};

Mit "struct foo" können sie immer angesprochen werden, ganz ohne
typedef. :)

Zweitens kann man sie vorwärts deklarieren:
struct foo;

struct bar {
   struct foo *foop;
   ...
};

Was natürlich nicht geht ist das, was du da gezeigt hast: ich
kann keine Struktur unbekannter Größe komplett in eine andere
einbetten.  Zirkular schon gar nicht, würde ja unendlich groß
werden. :-)  Zeiger darauf geht aber, den kann der Compiler bereits
festlegen, ohne die endgültige Größe der Struktur zu kennen.

Wenn man unbedingt auf die typedefs Wert legt, geht auch das:
typedef struct foo {
  ...
} foo;

Das ist sogar in C++ zulässig, obwohl dort "struct foo" unmittelbar
bereits den Namen "foo" im entsprechenden Scope definiert, auch ohne
weiteres Voranstellen von "struct".

: Bearbeitet durch Moderator
Autor: Bahara (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Hi!

Danke für die schnelle Antwort!

Also
File a.h:
#ifndef a_h_
#define a_h_

#include "b.h"

typedef struct MyStructB;
typedef struct MyStructA
{
  uint8 x;
  uint8 y;
  MyStructB z;
} MyStructA;

#endif /* a_h_ */

File b.h:
#ifndef b_h_
#define b_h_

#include "a.h"

typedef struct MyStructA;
typedef struct MyStructB
{
  uint8 af;
  uint8 fe;
  MyStructA be;
  MyStructA af;
} MyStructB;

#endif /* b_h_ */

Funktioniert nicht! :-(
Fehlermeldung vom Compiler:
"warning: empty declaration with storage class specifier does not 
redeclare tag"
bzw.
"useless storage class specifier in empty declaration"

Oder habe ich deine Lösung falsch verstanden?

Grüße
Bahara

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bahara schrieb:
> Hi!
>
> Danke für die schnelle Antwort!
>
> Also

[...] Du machst es ja immer noch wie im Original-Code:  Du willst ein 
unendlich großes Objekt kreieren.


> typedef struct MyStructA
> {
>   uint8 x;
>   uint8 y;
>   MyStructB z;
> } MyStructA;

also: sizeof(MyStructA) >= 2 + sizeof(MyStructB);

> typedef struct MyStructB
> {
>   uint8 af;
>   uint8 fe;
>   MyStructA be;
>   MyStructA af;
> } MyStructB;

also: sizeof(MyStructB) >= 2 + 2 * sizeof(MyStructA);

Rekursive Datenstrukturen gehen nur wie von Jörg erklärt via Zeiger.  Da 
Zeiger auch auf einen Incomplete Type zeigen dürfen, funktioniert das.

Autor: Markus F. (mfro)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Bahara schrieb:
> Oder habe ich deine Lösung falsch verstanden?

Offensichtlich.

Das ist kein C- sondern ein logisches Problem.

Woher soll der Compiler - wenn er sich an der einen struct müht - 
wissen, wie gross die andere ist (und umgekehrt)?

Wenn Du zwei Töpfe hast und in den einen passen 1 l plus der Inhalt des 
anderen Topfes, in den 2 l plus der Inhalt des einen passen, wie gross 
sind dann die beiden Töpfe?

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Zweitens kann man sie vorwärts deklarieren:
> struct foo;
>
> struct bar {
>    struct foo *foop;
>    ...
> };
>
> ...  Zeiger darauf geht aber, den kann der Compiler bereits
> festlegen, ohne die endgültige Größe der Struktur zu kennen.

Achte auf den * vor dem foop

Autor: Nixblicker (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Wo ist das Problem?

Wenn Header A beide Strukturen braucht, dann bitte dort deklarieren. 
Modul B nutzt ja beide Header. Also kein Problem.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nixblicker schrieb:
> Wo ist das Problem?

Das Problem ist die unendliche Rekursion der Structs. Ob in einem File 
oder in zweien spielt dafür wirklich keine Rolle, es geht weder in zwei 
Files noch in einem.

Ungefähre Analogie für jene, die an Unendlichkeiten scheitern: Wenn du 2 
Kartons vom Typ A hast und einen vom Typ B, und beide A-Kartons 
nebeneinander in den Karton B passen, dann ist der B-Karton grösser als 
beide A-Kartons zusammen. Also bekommst du den B-Karton definitiv nicht 
in einen der A-Kartons, ohne ihn zu zerquetschen.

: Bearbeitet durch User
Autor: W.S. (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Bahara schrieb:
> typedef struct MyStructB;

Begreife doch endlich mal, wozu was gut ist!
Du fummelst hier ständig mit "typedef" herum.
Hast du es denn nicht gelernt, daß typedef eben NICHT zum Definieren von 
Typen gut ist, sondern lediglich dazu, einem bereits bekannten Typ einen 
zweiten Namen zu geben?

Also, einen struct definiert man so:

struct name_des_struct { inhalt_des_struct };

und wenn man was umbenennen will, dann so:

typedef alter_name   neuer_name;

Ist dir das jetzt klarer geworden?

W.S.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Wenn du das Problem mit den rekursiven Structs in den Griff bekommen
hast, wartet schon das Problem mit den rekursiven Includes auf dich:


File a.h:
#ifndef a_h_
#define a_h_

#include "b.h"
...
#endif /* a_h_ */


File b.h:
#ifndef b_h_
#define b_h_

#include "a.h"
...
#endif /* b_h_ */

Die Dateien a.h und b.h includen sich gegenseitig. Rekursive Includes –
auch wenn sie wie bei dir mit Guards versehen sind, führen fast immer zu
(für Anfänger meist völlig unerklärlichen) Fehlern. Man sollte (und
kann) sie auf jeden Fall vermeiden.

Autor: A. K. (prx)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
W.S. schrieb:
> Ist dir das jetzt klarer geworden?

Als Anfänger von C(!) wäre ich jetzt noch verwirrter als vorher. Denn du 
verwechselst C mit C++.

Der Name einer struct hat in C einen eigenen Namespace, getrennt von 
allen anderen Namespaces, also auch dem Namespace der Typedefs. Ein 
Typedef ist also in C eben keine Umbenennung, sondern eine Abkürzung.
 struct S { ... };    // definiert die Struct S, aber nicht den Typ S
 typedef struct S S;  // definiert den Typ S als identisch mit "struct S"

> Hast du es denn nicht gelernt, daß typedef eben NICHT zum Definieren von
> Typen gut ist, sondern lediglich dazu, einem bereits bekannten Typ einen
> zweiten Namen zu geben?

Der typische Fall in C (nicht C++) ist tatsächlich die Definition von 
Structs im Rahmen eines Typedefs, unter Verwendung anonymer Structs:
  typedef struct { ... } S;

Einen Struct-Namen benötigt man nur für den hier relevanten Fall von 
Vorwärtsreferenzen:
 typedef struct S { struct S *p; } S;
In der Praxis sollte man die beiden S verschieden bezeichnen
 typedef struct S_s { struct S_s *p; } S_t;
um weniger zu verwirren. Nötig ist das aber nicht.

Typedefs sind in erst nachträglich zur Sprache hinzugefügt worden, 
wenngleich schon in K&R-C. Anfangs gab es keine Typedefs. Und sehr 
geglückt ist das Ergebnis nicht, nur muss man damit eben leben. Erst C++ 
hat das grundrenoviert, zum Preis möglicher Namenskonflikte.

: Bearbeitet durch User
Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier ist mal eine Möglichkeit, wie die Rekursionsprobleme unter
Beibehaltung der Typedefs aufgelöst werden können:


a.h:
#ifndef a_h_
#define a_h_

#include <stdint.h>
#include "b.h"

typedef struct MyStructA
{
  uint8_t x;
  uint8_t y;
  MyStructB z;
} MyStructA;

#endif /* a_h_ */


b.h:
#ifndef b_h_
#define b_h_

#include <stdint.h>

typedef struct MyStructA MyStructA;

typedef struct 
{
  uint8_t af;
  uint8_t fe;
  MyStructA *be;
  MyStructA *ef;
} MyStructB;

#endif /* b_h_ */

Die MyStructA-Elemente in MyStructB werden dabei durch Pointer ersetzt.
Damit ist schon einmal das Problem mit den unendlich großen Structs
gelöst.

Da in b.h wegen der Pointer-Deklarationen nicht der vollständige Typ von
MyStructA bekannt sein muss, kann auch das #include "a.h" entfallen.
Damit das anonyme Struct, das bisher nur den Typedef-Namen MyStructA
hat, trotzdem in b.h. (wenigstens als unvollständiger Typ) verwendet
werden kann, erhält es zusätzlich denselben Namen als Struct-Namen.
Durch diese beiden Änderungen ist die Include-Rekursion beseitigt.

Anmerkung: Der Typedef von MyStructA ist doppelt (in a.h und in b.h).
Derjenige in a.h ist eigentlich überflüssig, ich würde ihn aber aus
Gründen der besseren Verständlichkeit trotzdem beibehalten.

Alternativ oder zusätzlich könntest du aber auch das MyStructB-Element
in MyStructA durch einen Pointer ersetzen. Du könntest dann auch a.h in
b.h statt b.h in a.h includen. Welche der vielen Möglichkeiten die
letztendlich die praktischere ist, hängt davon ab, in welcher Weise du
die Structs in deiner Anwendung verwenden willst.

Noch eine letzte Anmerkung: Rindfleisch heißt auf Englisch "beef" und
nicht "beaf". Dieses Wissen hilft dabei, den letzten verbleibenden
Fehler zu beseitigen ;-)

Edit: Ach ja, ich habe auch die uint8 durch die in stdint.h normgemäß
deklarierten uint8_t ersetzt. Dann brauchst du diese Typen nicht selber
deklarieren.

: Bearbeitet durch Moderator
Autor: Bahara (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Abend zusammen!

Dank' euch! - Ich schau mal am Montag, wenn ich wieder in der Schule 
bin, ob ich es gelöst bekomme!

Viele Grüße
Bahara

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Wenn du das Problem mit den rekursiven Structs in den Griff bekommen
> hast, wartet schon das Problem mit den rekursiven Includes auf dich:

Eine Möglichkeit geht so:

a.h
#ifndef A_H_
#define A_H_

struct B; /* Defined in "b.h" */

typedef struct A
{
    int value;
    struct A *pA;
    struct B *pB;
} A;
#endif /* A_H_ */
 
b.h
#ifndef B_H_
#define B_H_

struct A; /* Defined in "a.h" */

typedef struct B
{
    double wert;
    struct A *pA;
    struct B *pB;
} B;
#endif /* B_H_ */

Die Reihenfolge, in der a.h bzw. b.h includet werden, spielt dann keine 
Rolle.  Es können sogar A-Objekte angelegt werden, ohne b.h zu includen:
#include <stddef.h>
#include "a.h"

A a = { 1, NULL, NULL };
Erst wenn versucht wird, einen Zeiger auf B zu dereferenzieren, meckert 
der Compiler, da struct B ohne Include von b.h "incomplete" ist:
#include <stddef.h>
#include "a.h"

A a = { 1, &a, NULL };

int main()
{
    a.pB->wert = 0;
}
 
Sowas kann garnicht compilieren, weil nirgendwo gesagt wurde, welche 
Komponenten struct B überhaupt hat:
 
In function 'main':
error: dereferencing pointer to incomplete type 'struct B'
     a.pB->wert = 0;
         ^~

Tatsächlich kann man dies als Feature verwenden, um eine rigorose 
Kapselung zu implementieren, welche die "Kapselung" in C++ mit "private" 
etc. an Strenge noch übertrifft:  Dazu nehmen wir zur Einfachheit an, 
dass sich das a-Modul auch um B kümmert, dessen Definition aber nicht 
offenlegt.  Jeglicher Zugriff auf Bs wird dann über Zugriffsfunktionen 
geregelt. Etwa:
#include "a.h"
/* Zusätzlich in "a.h" */
extern double B_get_value (const struct B*);
extern struct B* B_construct (double);

int main()
{
    A a = { 1, &a, B_construct (3.14) };
    printf ("Wert = %f\n", B_get_value (a.pB));
    /* B_free ... */
}
Wie B intern aufgebaut ist, bleibt Geheimnis des implementierenden 
Moduls, hier von a.c
#include <stdlib.h>
#include "a.h"

typedef struct B
{
    double wert;
    struct A *pA;
    struct B *pB;
} B;

double B_get_value (const B *b)
{
    return b->wert;
}

B* B_construct (double value)
{
    B *b = malloc (sizeof (B));
    b->wert = value;
    b->pA = NULL;
    b->pB = NULL;

    return b;
}

Alles, was Module außer a.c über B zu wissen brauchen, ist der Name der 
Struktur, und alle Module außer B bekommen lediglich ein "Handle"; hier 
die Adresse eines B.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.