WINAVR Platzhalter (.)

Maik schrieb:
> Das ist eine PreCompiler Anweisung, das hat nichts mit C zu tun.

Das ist eine Wurzel, das hat nix mit Pflanzen zu tun.

Nimm doch einfach einen "neuen" Präprozessor und weiterhin den "alten" 
Compiler :-)

Sven P. schrieb:
> Ist auch nicht sonderlich schön, diese Art von Makros zu benutzen.

Wenn ich mir anschaue, welche Verrenkungen (doppelte Klammern anyone) 
früher nötig waren, um z.B. ein DEBUG()-Makro zu definieren, das wie 
printf() benutzt werden kann, aber per #define ein-/ausgeschaltet werden 
kann, dann bin ich froh, dass es inzwischen standardkonform variadische 
Makros gibt (GCC z.B. hatte die ja als Erweiterung mit anderer Syntax 
schon wesentlich länger).

Peter schrieb:
> Für mich ist es nur Blöd das jemand so was nutzt, da ich mit dem Code
> nicht auf alte Compiler wandern kann.

Genau, am besten sollten auch im 3. Jahrtausend alle noch K&R-C 
schreiben. Funktionsprototypen sind Teufelszeug ;-)

Sei froh, dass es nicht wie teilweise im PC-Bereich ist, wo sich 
manchmal schon gerade mal 1 Jahr alter Code mit den aktuellen Versionen 
der verwendeten Libraries nicht mehr ohne Änderungen kompilieren lässt 
(und damit meine ich jetzt nicht Major-Releases der Libs, bei denen das 
API komplett überarbeitet worden wäre)...

> Ich habe noch alte Projekte (vor 1990) und Compiler. Diese Projekte
> werden niemals portiert aber immer noch erweitert.

Dann musst du damit leben, dass du neueren Code eben nicht einfach 
übernehmen kannst. Wenn sich alle danach richten sollten, dass du den 
Code möglichst einfach in deine Uralt-Projekte (und ja, nach 
IT-Maßstäben ist dein Prä-ANSI-C-Code echt antik) integrieren kannst, 
dann gäbe es keinen Fortschritt mehr. Die vielen von C99 geschaffenen 
Möglichkeiten, Code sauberer, verständlicher und portabler zu schreiben 
(stdint.h for president ;-) gingen dabei verloren.

Wenn jemand heute noch (ausserhalb von Projekten vergleichbar mit 
deinen) ohne äußerste Not neuen C-Code unter expliziter Vermeidung von 
C99-Neuheiten schreibt, so gehört er IMO standrechtlich erschossen (im 
übertragenen Sinne natürlich ;-). Dass es immer noch aktuelle 
C-Compiler ohne (vollständige) C99-Unterstützung gibt ist natürlich noch 
ein anderes Thema...

Neben der reinen Syntax gibt es ausserdem noch andere Aspekte, weswegen 
man modernen Code auf keinen Fall einfach auf alte Compiler übernehmen 
sollte, selbst wenn er prinzipiell kompiliert. Ein Punkt ist z.B. die 
heute übliche Verwendung von Inline-Funktionen an Stellen (z.B. in 
Headern), wo man früher dafür ein Macro verwendet hätte, selbst dann, 
wenn man weiss, dass das wirklich nur mit Inlining und Optimizer 
funktioniert (Stichwort _delay_ms() z.B.). Man kann sich bei heutigen 
Compilern in sehr vielen Fällen wirklich darauf verlassen, dass die 
Funktion tatsächlich geinlined wird (natürlich darf dann nur mit 
Optimizer kompiliert werden). Bei einem Uralt-Compiler geht das dann 
aber schnell mal sprichwörtlich in die Hose.

Noch ein Punkt ist, dass auch im Hinblick auf wirklich langfristige 
Wartbarkeit der Code irgendwann portiert werden muss. Je länger man 
damit wartet, desto schmerzhafter wird es in der Regel dann.

K&R-C ist dafür wohl noch nicht lange genug Vergangenheit, aber nimm 
z.B. die Jahr-2000-Geschichte, als lauter COBOL-Entwickler in Rente sich 
eine goldene Nase verdient haben. Wer heute C neu lernt, der sieht (wenn 
überhaupt) eine Funktion in alter K&R-Form höchstens noch irgendwo als 
Randbemerkung, bei der unfallfreien Übergabe von Parametern an eine 
solche Funktion ist dann endgültig Schluss.

Lass nochmal 20 Jahre ins Land gehen, dann werden die Reihen der 
Entwickler, die K&R noch wirklich beherrschen, sich langsam aber 
sicher auf natürlichem Wege lichten, mal davon abgesehen, dass ich es 
nicht komplett ausschliessen will, dass vielleicht auch C allgemein bis 
dahin schon ein gutes Stück des endgütligen Weges in die Geschichte oder 
die kleinen Restnischen zurückgelegt hat.

Nichts ist so konstant wie die Veränderung ;-)

Andreas