Frage zu #include
-
Hallo,
das Problem ist nicht einfach zu formulieren, doch ich versuch's mal. Ich untersuche zur Zeit ein größeres C-Programm, das aus etlichen Modulen (jeweils h und c) besteht. Da die Module kreuz und quer voneinander abhängig sind, versuche ich, ein wenig Ordnung reinzubringen. Einige Includes scheinen auch überflüssig zu sein. So habe ich z.B. probehalber in Modul A das #include "B.h" auskommentiert. Compiler und Linker meldeten keinen Fehler, obwohl in A auf eine Funktion von B zugegriffen wird. Ok, ich merkte dann, dass die Funktion rechts von einer Zuweisung steht, so dass hier der Linker Alarm schlagen müsste. Tat er aber nicht, wahrscheinlich, weil der Header B auch von C und X und Z eingebunden wird und somit die Funktion von anderer Stelle kompiliert wurde (berichtigt mich, wenn ich was Falsches denke).
Nur, und jetzt kommt es: Nach dem Löschen von #include "B.h" in A stieg das Programm mit einem Laufzeitfehler aus (irgendeine Variable mit falschem Inhalt, die ein check_assertion auslöste). Wie kann es sein, dass der Fehler sich nicht einstellt, wenn der Header B eingebunden wird?
-
Ohne wahlweise kompletten Source oder Kristallkugel wird dir da keiner helfen können. --> Debugger findest wohl selber...
Greetz, Swordfish
-
das kann z.b. passieren, wenn in der .h ein funktionsprototyp steckt, der dem compiler jetzt fehlt und er deshalb annimmt, die funktion habe einen rückgabewert 'int' und einen einzelnen parameter (auch 'int').
btw: wenn du mittelgrosse c-projekte untersuchen willst: http://www.scitools.com/products/understand/cpp/product.php
-
ten schrieb:
das kann z.b. passieren, wenn in der .h ein funktionsprototyp steckt, der dem compiler jetzt fehlt und er deshalb annimmt, die funktion habe einen rückgabewert 'int' und einen einzelnen parameter (auch 'int').
Oder falls der Funktionsprototyp fehlt, schlagen auch die impizieten Casts in den richtigen Typ fehl. Am besten du schaltest mal die Warnungen deines C-Compilers ein.
-
Dass überhaupt Inkonsistenzen auftreten können, wenn ein Programmteil "von hinten herum" ins Programm rutscht, ist ein sehr wichtiger Hinweis, danke. Ist irgendwie logisch. Man sollte also darauf achten, dass immer Prototyen griffbereit sind. Mit den eingeschalteten Warnungen lässt sich das ja gut kontrollieren.
Weiß der Henker, warum ich -Wall abgeschaltet hatte. Ich stellte nun fest, dass es von "imlipicit declaration of function" nur so wimmelte. Der Grund lag darin, dass einige häufig benutzte Module schon über die Header weitergereicht wurden. Ich mag es nicht, dieses Einbinden von Headern auf Umwegen und hatte zu stark aufgeräumt, ohne darauf aufmerksam gemacht zu werden.
Reinhard
