Gibt es eine Möglichkeit zu erkennen, wenn Dateiabhängigkeiten "zufällig" erfüllt sind?

8

Sagen wir, es gibt drei Header AAA.h , BBB.h und MyLib.h . MyLib.h muss sowohl AAA.h als auch BBB.h enthalten, um ordnungsgemäß zu funktionieren.

Nun, es passiert einfach, dass BBB.h auch AAA.h enthält, aber dies ist ausschließlich auf die Implementierung zurückzuführen, ein Detail, das MyLib.h nicht interessieren sollte.

Der Verfasser von MyLib.h ignoriert jedoch versehentlich AAA.h und bemerkt dies nie. Dies führt normalerweise nicht zu einem Fehler oder einer Warnung, soweit ich weiß. Später ändert jemand die Implementierungsdetails von BBB.h , so dass AAA.h nicht mehr benötigt wird und somit entfernt wird. Jetzt kompiliert MyLib nicht, da sich die Interna der Bibliothek BBB geändert haben.

Gibt es in solchen Fällen eine Möglichkeit zu Fehlern oder Warnungen? Ich vermute (wenn das überhaupt möglich ist), dass es eine Art Annotation in der Kopfzeile benötigt, die enthalten ist.

    
Alex 17.07.2011, 08:54
quelle

2 Antworten

2

Ich denke, es ist am besten zu vermeiden, abhängig von anderen Headern in öffentlichen Schnittstellenheadern, so dass dieses Problem nicht auftritt.

Öffentliche Schnittstellenheader sollten keine unnötigen Definitionen enthalten.

Es gibt verschiedene Tricks, um Dinge ohne Include-Dateien zu tun. Zum Beispiel können Sie Struktur-Tags manuell deklarieren, wenn Sie nur einen Zeiger benötigen (Bibliotheken, die nur einen Typdef definieren, frustrieren dies) und Sie können _Bool anstelle von bool verwenden, um <stdbool.h> zu vermeiden. Leider sind viele wichtige Typen wie size_t und uint32_t nur in Headern definiert.

Einige Pakete gehen so weit, dass sie ihr eigenes foo_uint32_t mit configure definieren, so dass sie <stdint.h> nicht in ihre öffentlichen Interface-Header aufnehmen müssen. Dies ist ziemlich schwierig, da die Typen genau gleich sein müssen, um Verwirrung zu vermeiden: auch wenn sizeof(unsigned int) == sizeof(unsigned long) == 4 unterschiedliche Typen sind. Daher ist es möglicherweise nicht wert.

    
jilles 18.07.2011, 12:50
quelle
2

Sie veranschaulichen, warum das Einfügen von Headern als Methode zum Importieren von Namespaces angezeigt wird.

Die einzige Lösung, die ich sehe, ist Disziplin. Standard-Bibliotheksfunktionen erfordern, dass Sie die entsprechende Kopfzeile enthalten, Ihre Projekte sollten den gleichen Standard übernehmen. Header wie MyLib.h sollten nur die von ihr definierten Typen und ihre Funktionsprototypen enthalten. Wenn es einen bestimmten Typ benötigt, um seine Aufgabe zu erledigen, sollte der Header explizit eingefügt werden. Wenn er also eine Definition von AAA benötigt, sollte er AAA.h enthalten und wenn er eine Definition von BBB benötigt, sollte er% enthalten co_de%, ebenso sollten alle Implementierungsdateien (sagen wir BBB.h ) explizit alle Header für alle verwendeten Definitionen enthalten, unabhängig davon, ob MyLib.c sie auch enthält. Gehen Sie niemals davon aus, dass ein Header implizit definiert, indem Sie andere Header einfügen.

Dies kann leicht mit einer IDE überprüft werden, die Ihnen normalerweise sagt, wo ein Name definiert ist, und so können Sie leicht herausfinden, welche Include-Datei verwendet werden soll. Es kann Tools geben, die diese Art der Überprüfung durchführen.

    
deStrangis 18.07.2011 11:05
quelle

Tags und Links