Re: Suche eine spezielle Präsentation zu Coding Guidelines
Andre Heine <[email protected]>
| Newsgroups | gmane.linux.suse.programming |
|---|---|
| Organization | none |
| Message-ID | <[email protected]> |
Moin moin, Am Donnerstag, 22. Februar 2007 13:41 schrieb Ralf Corsepius: > > > > http://www.linuxjournal.com/article/5780 > > > > > > > > Hier steht zumindest, warum "ifdefs" nicht in > > > > .c Code erwünscht sind ... > > > > > > ... im Kernel-Code erwünscht sind ... > > > > > > Vorsichtig formuliert, würde ich dort vorgebrachten Argumente > > > bez. #ifdefs als "sehr streitbar" bezeichnen. > > > > IMHO ist das eine Entscheidung, die der Entwickler treffen muss. > > Technisch spricht AFAIK nichts gegen irgendwelche defines in den > > *.c oder *.h Dateien. > > Und ob. > Defines in public *.h's führen zu einer "define-abhängigen API", zu > potentiellen define-Clashes zwischen Paketen und verführen > unbedarfte User dazu, defines zu benutzen um sich selbst > auszutricksen. Design technisch ACK... Der Compiler macht ja keinen Unterschied, ob ein Header im eigenen Paket ist oder public. (oder doch???) Ist ein bisschen wie "goto". Die meisten hassen, andere lieben es:) Aber "irgendwie" bekommt man es hin, wenn man aufpasst. Dazu gibt es ein paar nette Kommentare: C++ makes it much harder to shoot yourself in the foot, but when you do, it blows off your whole leg. - Bjarne Stroustrup In C we had to code our own bugs. In C++ we can inherit them. -Prof. Gerald Karam > Gegen defines in privaten *.h's und *.c's spricht nicht viel, da > sie nur lokal, innerhalb eines Paketes verwendet werden. > > Siehe auch das Kommentar im obigen Link... > > > > Nimmt z.B. C++, wird suggeriert, dass "inlines" "defines" > > vorzuziehen sind. Sieht auch viel schöner aus... > > Ist nicht nur schöner, ... inlines sind typen-streng, defines > nicht. Jep... Ciao Andre