c't

c't-Projekte - Mailinglisten


[Voriger (Datum)] [Nächster (Datum)] [Voriger (Thread)] [Nächster (Thread)]
[Nach Datum][Nach Thread]

Re: [ct-bot] Ein kleiner Korrekturvorschläge

Absender: Simon Siemens
Datum: Fr, 18.03.2011 17:45:50
In-reply-to: <7D633C42-57A6-4FDD-B3E2-9BFECE4990F7@xxxxxxxxxxxxxxx>
References: <1300351734.1889.7.camel@wbam-laptop> <B4B15A51-ED01-4DF1-8F7C-3F8FE2BBE60B@xxxxxxxxxxxxxxx> <1300373124.1889.30.camel@wbam-laptop> <7D633C42-57A6-4FDD-B3E2-9BFECE4990F7@xxxxxxxxxxxxxxx>


Hi Timo,

ok, ich denke du willst mÃglichst weitgehend das erste Schema umsetzen.
Damit ist mein Korrekturvorschlag natÃrlich hinfÃllig. Wir werden es bei
unseren weiteren Arbeiten berÃcksichtigen.

Wie du merkst, arbeiten wir im Moment auch an Sachen, die du unter
UmstÃnden als Kleinigkeiten und als unwichtig betrachtest. Ich hoffe,
das ist fÃr dich dennoch in Ordnung. Unser Ziel ist, dass auch komplette
ProgrammieranfÃnger bereits erste Schritte mit dem ct-Bot machen. Darum
sind wir sehr bemÃht, dass alles, womit unsere Kursteilnehmer in
BerÃhrung kommen, eher poliert ist. Die Teilnehmer sollen sich vor allem
auf die Algorithmen konzentrieren und sich mÃglichst wenig mit der
Installation und anderen Kleinigkeit beschÃftigen mÃssen.
Roboterprogrammierung ist dafÃr nur bedingt geeignet. Wir merken aber,
dass sie unsere Teilnehmer sehr motiviert. :-)

Herzliche GrÃÃe,

Simon


Am Donnerstag, den 17.03.2011, 17:39 +0100 schrieb Timo Sandmann:
> Hallo Simon,
> 
> Am 17.03.2011 um 15:45 schrieb Simon Siemens:
> > 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.
> 
> ja du hast vÃllig Recht, dass das im Bot-Code nicht konsistent ist. Im devel-Zweig ist es schon ein wenig aufgerÃumter, aber auch nicht vollstÃndig. Letztlich hat das eben keine so hohe PrioritÃt, solange alles funktioniert. 
> Hinzu kommt, dass wir Eclipse als Editor benutzen, welches inaktive #if-Zweige automatisch ausblenden oder anders einfÃrben kann. Das ist extrem hilfreich bei den vielen #define-Konfigurationen im Bot-Code. Damit das auch fÃr Header-Dateien vernÃnftig klappt, muss aber die Headerdatei, die den #ifdef-Schalter enthÃlt, eingebunden sein, sonst kann der Eclipse-Indexer nicht beurteilen, welche Zweige aktiv sind und welche nicht. Gleiches gilt fÃr die Makro-Expansion. Auch daher gibt es teilweise unnÃtige #includes in einigen Headerdateien. 
> GrundsÃtzlich hat das Schema 2. die Nachteile, dass a) zirkulÃre AbhÃngigkeiten entstehen kÃnnen und b) mehr Zeit zum Compilieren benÃtigt wird, wenn eine Headerdatei durch viele Indirektionen x-mal eingebunden wird. Ich wÃrde das daher lieber auf ein Minimum beschrÃnken. Auch der bestehende Code mÃsste da noch mal stÃrker aufgerÃumt werden (insbesondere bei den Verhalten ist das sonst nervig - daher gab es da bisher auch die meiste AufrÃumaktivitÃt). BlÃd ist nur immer, wenn dann in einem per default abgeschaltetem Teil ein #include fehlt, was nicht sofort auffÃllt und dann bei jemand anderem zum Fehler fÃhrt. 
> 
> Gerade, wenn ihr Teile zusammen mit anderem Code nutzen wollt, ist es doch besser, wenn die Headerdateien von mÃglichst wenigen anderen abhÃngen. HÃngen sie von anderen ab, die ihr evtl. gar nicht braucht, kÃnnt ihr sie wegen der #includes trotzdem nicht weglassen. 
> 
> Variante 3. ist sicherlich perfekt, wenn sie unter allen Konfigurationen auch funktioniert, macht aber auch die meiste Arbeit. Der Bot-Code ist eigentlich nicht als Bibliothek designed, vieles (wie auch das Include-Schema), hat sich historisch einfach so entwickelt. 
> 
> > Was meinst du?
> 
> Wenn ihr die nÃtigen Headerdateien in euren C-Datein einbindet, seid ihr unabhÃngig davon, wenn im ct-Bot-Code mal aufgerÃumt wird. So wÃrde ich es jedenfalls machen, weil der Aufwand recht gering ist. 
> 
> GrÃÃe,
> Timo
> 
> 
> 
> _______________________________________________
> ct-bot-entwickler Mailingliste
> ct-bot-entwickler@xxxxxxxxxxxxxxxxx
> http://www.heise.de/bin/newsletter/listinfo/ct-bot-entwickler