typedefs über mehrere Header-Dateien bekannt machen

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • typedefs über mehrere Header-Dateien bekannt machen

    Hallo zusammen,

    ich habe jetzt des öfteren ein Problem gehabt, welches ich meiner Meinung nach immer recht unsauber gelöst habe - und nun will ich es gerne einmal richtig machen;)

    Wenn ich zwei Klassen definiert habe (classA & classB), und ich diese untereinander bekannt machen will geht es wunderbar mit der @class Direktive. Wenn ich nun aber in beiden Header-Dateien typedefs definiert habe, und ich diese auch untereinander nutzen möchte, hakt es leider.

    classA.h

    Quellcode

    1. #import "classB.h"
    2. #import <Foundation/Foundation.h>
    4. typedef enum{enumAvalue1} enumA;
    5. @interface classA : NSObject
    6. +(void)aa:(enumB)value;
    7. @end


    classB.h

    Quellcode

    1. #import <Foundation/Foundation.h>
    2. #import "classA.h"
    4. typedef enum{enumBvalue1} enumB;
    6. @interface classB : NSObject
    7. +(void)bb:(enumA)value;
    8. @end



    Gibt es hier eine andere Lösung als die typedefs in einer Header-Datei zu platzieren, und diese Datei dann in classA.h und classB.h zu importieren, und den gegenseitigen #import durch die @class Direktive zu ersetzen.


    Mich stört an einer globalen "typedef.h"-Datei die Tatsache, dass die dort definierten enums logisch eher zu den in den Header-Files (classA.h, classB.h) definierten Klassen/Protokollen gehören.


    Hat hier jemand eine schlaue Antwort parat?


    Viele Grüße aus Neuseeland
    Dennis
    "Die Steinzeit ging auch nicht zu Ende weil die Steine ausgingen"

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von jakez ()

  • Ne, geht nicht. Mit @class "versprichst" du ja quasi nur, dass du die Eigenschaften und Methoden der Klasse später kennst. In der m-Datei von Klasse B musst du ja auch Klasse A importieren. Wenn du natürlich im Header von Klasse A dein typedef schon brauchst, dann musst du Klasse A dort bereits importieren. Gruß Alex P.S.: Wo biste in Neuseeland?

  • @Alex:

    Japp - ist mir leider bekannt :-/ - Bin zZ in Christchurch. Aber in 2 Wochen geht es los auf Tour - einen Monat mit dem Auto Querfeldein ;)


    @DD

    Kannst du das bitte einmal kurz erörtern? Denn ich kenne die Prefix.pch auch nur als "die eine Stelle", an der ein paar Hilfsmacros etc. definiert werden können.


    Grüße!
    "Die Steinzeit ging auch nicht zu Ende weil die Steine ausgingen"

  • Ich finde nichts verwerfliches daran eine Header Datei in einem Header zu importieren wenn Symbole daraus benötigt werden. Der einzige Nachteil der sich daraus ergibt und warum es neuerdings nicht mehr als Die feine Art gesehen wird ist, dass man aufpassen muss das die Datei gegen doppelte Importierung gesichert ist.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Ich finde nichts verwerfliches daran eine Header Datei in einem Header zu importieren wenn Symbole daraus benötigt werden. Der einzige Nachteil der sich daraus ergibt und warum es neuerdings nicht mehr als Die feine Art gesehen wird ist, dass man aufpassen muss das die Datei gegen doppelte Importierung gesichert ist.

    Doppelte „Importierung“ dürfte schwer fallen. Im Gegensatz zu #include verhindert #import das ja gerade.

    Michael

  • Hallo zusammen,

    erstmal vielen Dank für eure Antworten!!!

    Thallius schrieb:

    Ich finde nichts verwerfliches daran eine Header Datei in einem Header zu importieren wenn Symbole daraus benötigt werden.
    Ich ja auch nicht;) - aber sobald ich in zwei Header-Dateien (classA.h und classB.h) die jeweils andere Header-Datei importiere, habe ich eine Schleife, und die mag er nicht. Aber diese gegenseitige Bekanntmachung ist, wie oben schon geschrieben, leider unabdingbar, wenn ich in den Header-Dateien Funktionen definiere, die Parameter erwarten die in den jeweils anderen Header-Dateien definiert sind (enumA und enumB).

    Und genau dafür suche ich eine Lösung die hoffentlich nicht heißt: Packe alle typedefs an eine zentrale Stelle.

    Thallius schrieb:

    Der einzige Nachteil der sich daraus ergibt und warum es neuerdings nicht mehr als Die feine Art gesehen wird ist, dass man aufpassen muss das die Datei gegen doppelte Importierung gesichert ist.
    Hierfür wurde ja, wenn ich das richtig verstanden habe, der #import eingeführt. Dieser ist nämlich ein verbesserte Version des #include's, welcher die doppelte Importierung verhindert.
    "Die Steinzeit ging auch nicht zu Ende weil die Steine ausgingen"

  • jakez schrieb:

    Hallo zusammen,

    erstmal vielen Dank für eure Antworten!!!

    Thallius schrieb:

    Ich finde nichts verwerfliches daran eine Header Datei in einem Header zu importieren wenn Symbole daraus benötigt werden.
    Ich ja auch nicht;) - aber sobald ich in zwei Header-Dateien (classA.h und classB.h) die jeweils andere Header-Datei importiere, habe ich eine Schleife, und die mag er nicht. Aber diese gegenseitige Bekanntmachung ist, wie oben schon geschrieben, leider unabdingbar, wenn ich in den Header-Dateien Funktionen definiere, die Parameter erwarten die in den jeweils anderen Header-Dateien definiert sind (enumA und enumB).

    Und genau dafür suche ich eine Lösung die hoffentlich nicht heißt: Packe alle typedefs an eine zentrale Stelle.

    Thallius schrieb:

    Der einzige Nachteil der sich daraus ergibt und warum es neuerdings nicht mehr als Die feine Art gesehen wird ist, dass man aufpassen muss das die Datei gegen doppelte Importierung gesichert ist.
    Hierfür wurde ja, wenn ich das richtig verstanden habe, der #import eingeführt. Dieser ist nämlich ein verbesserte Version des #include's, welcher die doppelte Importierung verhindert.


    du musst sie ja nicht ALLE in einen header packen sondern kannsts header anlegen wieviel du willst.

  • Ich habe dir einmal ein kleines Demoprojekt angehängt.Dort sind eigentlich nur die oben beschriebenen Head-Dateien eingebunden. Xcode sagt hier leider in beiden Header-Dateien, dass der entsprechende Typ (enumA bzw enumB) nicht bekannt ist.
    "Die Steinzeit ging auch nicht zu Ende weil die Steine ausgingen"

  • @gritsch:

    Danke! Ich habs befürchtet. Ich hatte bis zuletzt noch Hoffnung, dass man das Problem evtl. mit einem

    #ifndef _b_h_included_
    #define _b_h_included_
    #endif


    o.ä. lösen könnte. Ich danke dir für deine Mühe, ich werde es jetzt wie von dir beschrieben lösen - Hoffnung gestorben;)


    Grüße!
    "Die Steinzeit ging auch nicht zu Ende weil die Steine ausgingen"

  • Joah, wenn TypeDefs logisch zu einem Protokoll gehören, das von zwei Klassen bedient wird, dann lager' das Protokoll aus.

    Viel Spannender finde ich ja die Frage, warum jetzt beide Klassen Typdefinitionen voneinander benötigen, aber gut.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Michael schrieb:

    Thallius schrieb:

    Ich finde nichts verwerfliches daran eine Header Datei in einem Header zu importieren wenn Symbole daraus benötigt werden. Der einzige Nachteil der sich daraus ergibt und warum es neuerdings nicht mehr als Die feine Art gesehen wird ist, dass man aufpassen muss das die Datei gegen doppelte Importierung gesichert ist.

    Doppelte „Importierung“ dürfte schwer fallen. Im Gegensatz zu #include verhindert #import das ja gerade.

    Im Normalfall schon. Ich hatte allerdings gerade bei einer Lib das lustige Phänomen, dass ein Importloop zu unerklärlichen 'Cannot find procotol declaration', 'expected a type' und ähnlichen Fehlermeldungen führte.

    #import verhindert also offenbar nur Importloops von Projektdateien ("header.h"), nicht von Bibliotheken oder Frameworks (<header.h>).
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Lucas de Vil schrieb:

    Michael schrieb:

    Doppelte „Importierung“ dürfte schwer fallen. Im Gegensatz zu #include verhindert #import das ja gerade.

    Im Normalfall schon. Ich hatte allerdings gerade bei einer Lib das lustige Phänomen, dass ein Importloop zu unerklärlichen 'Cannot find procotol declaration', 'expected a type' und ähnlichen Fehlermeldungen führte.

    #import verhindert also offenbar nur Importloops von Projektdateien ("header.h"), nicht von Bibliotheken oder Frameworks (<header.h>).

    Ich glaube nicht, dass die Fehlermeldungen darauf hin deuten, dass eine Header-Datei doppelt importiert wurde. Da erwarte ich dann schon Fehlermeldungen wie 'redeklaration' oder 'double/multiple deklaration' oder so ähnlich. Das etwas nicht gefunden wird, weil etwas doppelt importiert wurde, grenzt an Woodoo. #import macht ganz bestimmt keinen Unterschied zwischen Headerdateien aus einem Projekt oder einem Framework.

    Michael