Hallo, ich habe einen C Code bekommen und da wurde ein Platzhalter benutzt. Ich meine: #define PRINT(...) Ist das nun C oder C++? Ich finde nichts was mir mal sagt, das das überhaupt geht. Der GCC schluckt das, aber der hält sich ja auch nicht an den C Standard. Dirk
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.
Für mich ist es nur Blöd das jemand so was nutzt, da ich mit dem Code nicht auf alte Compiler wandern kann. Ich habe noch alte Projekte (vor 1990) und Compiler. Diese Projekte werden niemals portiert aber immer noch erweitert.
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. Nach diesem Argument müssten wir allen noch immer nach dem C68-Standard Programmieren... ;-)
Warum den nicht? Wer braucht schon das ganze neumodische Zeug. Ich umgehe so was, allein schon aus Unkenntnis, sonst hätte ich ja nie hier gefragt.
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
Das ist alles richtig was Du sagst. Aber ich hatte erst letzte Woche so meine Erfahrung mit "_delay_us()" gemacht. Ich musste mein kleinstes 8051 Projekt (31 Files alle von 1989, ca. 12.000 Zeilen) auf einen AVR mit WINAVR portieren. Also 2 Umbauten. Die erst Hürde 8051 (Keil) auf AVR (IAR) war schnell gemacht und läuft. Dann dachte ich mir warum den Uralt IAR nehmen, wenn es was neueres gibt. IAR auf WINAVR ging auch. Aber dann wollte ich auch die Delay Funktionen austauschen. Compiler hat nicht gemeckert, aber der Code lief überhaupt nicht mehr. Im Debugger wurde wild hin und her gesprungen. Also habe ich alle neuen Delay Funktinen wieder durch die alten ersetzt und habe das Projekt abgeschlossen. Der Code ist übrigens Top wartbar. Es hängt nicht von solchen Macros ab sonder wie man Code aufschreibt und das wird heute nicht mehr so sauber gemacht wie damals. Der Editor spielt auch eine wichtige Rolle. Wer mit Edit ankommt sollte lieber gleich auf hören. Ein #ifdef #else #endif sollte der mindestens auflösen können. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.