www.mikrocontroller.net

Forum: Compiler & IDEs WINAVR Platzhalter (.)


Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: der mechatroniker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Such mal nach "variadic macros", so heißen die Dinger nämlich.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke.

Da ist mein C Standard wohl noch ein Alter.

Dirk

Autor: Maik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist eine PreCompiler Anweisung, das hat nichts mit C zu tun.

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seit C99 ist das erlaubt. Das passende Argument dazu heißt _VA_ARGS_.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist auch nicht sonderlich schön, diese Art von Makros zu benutzen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

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

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.