Absender: Simon Siemens
Datum: Do, 17.03.2011 15:45:27
In-reply-to:
<B4B15A51-ED01-4DF1-8F7C-3F8FE2BBE60B@xxxxxxxxxxxxxxx>
References:
<1300351734.1889.7.camel@wbam-laptop> <B4B15A51-ED01-4DF1-8F7C-3F8FE2BBE60B@xxxxxxxxxxxxxxx>
Hallo Timo, ich sehe den Punkt eher im Folgenden: Mir sind drei Ãbliche Varianten bekannt, mit Headerdateien umzugehen: 1. Eine Headerdatei bindet keine weiteren Headerdateien ein. Das ist den C-Dateien Ãberlassen. Dies entspricht in etwa deinem Vorschlag, global.h in jede C-Datei einzubinden. Hier muss jede C-Datei dann selbst wissen, in welcher Reihenfolge die Header eingebunden werden mÃssen. 2. Eine Headerdatei bindet alle anderen Headerdateien ein, deren Typen und Funktionen sie benutzt. Die Headerdatei ist dann in sich geschlossen. 3. Bibliotheken (z.B. GTK+) benutzen auch teilweise das Schema, dass der Anwender nur eine Headerdatei (gtk.h) einbinden soll, die sich um die richtige Reihenfolge aller Headerdateien kÃmmert. Bisher schien mir, dass der ct-Bot-Code das zweite Schema umsetzt. Beispielsweise ist ct-Bot.h in fast allen anderen Headerdateien direkt eingebunden. Und auch global.h ist in vielen Headerdateien (adc.h, ena.h, fifo.h, ir-rc5.h, math_utils.h, motor.h, motor-low.h, pos_store.h, sensor.h, sp03.h srf10.h, tcp.h und twi.h). In der Konsequenz wÃrde ich sagen, bei display.h fehlt sie. (Sonst mÃsste sie auch nicht in motor.h sein.) *Es geht also lediglich um Konsistenz.* Das ganze ist dann relevant, wenn man nicht die bestehenden Behaviour-Codes benutzen will, sondern selbst welche schreiben will. Der Code soll sich dann wie aus einem Guss anfÃhlen und einfach zu handhaben sein. Was meinst du? GruÃ, Simon Am Donnerstag, den 17.03.2011, 13:51 +0100 schrieb Timo Sandmann: > Hi, > > Am 17.03.2011 um 09:48 schrieb Simon Siemens: > > Hallo Timo, > > > > ich bin noch Ãber einen Mini-Bug gestoÃen: > > > > display.h nutzt uint8_t. Es sollte deshalb global.h einbinden. > > warum sollte deshalb global.h in der Headerdatei eingebunden werden? Jede .c-Datei bindet (Ãber ct-Bot.h) zuerst global.h ein, damit ist global.h schon Ãberall eingebunden, wo display.h eingebunden werden kÃnnte. Ein zusÃtzliches #include in display.h wÃrde also nichts Ãndern (wegen des #ifndef GLOBAL_H_-Blocks). > > GrÃÃe, > Timo > > > _______________________________________________ > ct-bot-entwickler Mailingliste > ct-bot-entwickler@xxxxxxxxxxxxxxxxx > http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler