Hallo,
Meistens trifft der Compiler auch die Stelle, aber:Zitat von Wsk8
1. Der Pre-Prozessor funktioniert, etwas vereinfacht, wie "suchen und ersetzen" in einen Texteditor. Fehler welche durch Macros entstehen, treten daher nicht an der Stelle wo das "#define" steht auf, sondern dort wo das Macro verwendet wird.
2. Selbiges gilt auch, wie in diesem Fall, für fehlende "typedef". Wobei ich jetzt keine Ahnung habe, wie die Definition in der verwendeten Implementierung gemacht wird. Grundsätlich ist die Verwendung von "typedef" und "#define" in diesem Fall gleichwertig.
3. Eine fehlende "}" wird oft erst bei der Definition der nächsten Funktion erkannt. Das liegt an der gültigen Syntax von C.
uint8_t gibt es in Standard-C erst seit C99.
Compilertechnisch, bleibt es aber ein selbst definierter Datentyp.
Das dieser in stdint.h hinterlegt ist, ist eine implementierungsspezifische Erweiterung, dieser muss nicht in einer konkreten Implementierung vorhanden sein.
Hier mal die Datentypen welche Standard-C kennt:
http://en.wikipedia.org/wiki/C_data_types
C ist wohl die am meisten falsch verstandene Sprache.
Der Compiler kennt nur um die 30-40 Schlüsselwörter und eine Hand voll Operatoren.
Der ganze Rest wie z.B. itoa();, printf(); usw., sind Funktionen welche sich in, heute standartisierten, Bibliotheken befinden und sich aber, aus Sicht des Compilers, in keiner Weise von eigenen Funktionen unterscheiden.
Ursprünglich, nach K&R, waren die ganzen Bibliothen nicht direkter Bestandteil der Sprachdefinition.
Dies mach aber die ganze Stärke von C aus!
In Pascal gab es z.B. keine Möglichkeit, Funktionen mit variabler Parameterzahl zu schreiben. Einzig write() konnte dies, weil write() ein Schlüsselwort war und der Compiler bei diesem eine Ausnahme machte. Änlich ist es bei BASIC mit PRINT.
Bei C kann ich problemlos das printf() durch eine eigene Funktion ersetzen und dann Programme, ohne Änderung, überersetzen und mit meinem printf() linken.
Auch kann man in C ein eigenes Dateisystem schreiben. Ich habe das bei vielen µP-Anwendungen gemacht. Da gab es vielleicht nur zwei Datwenstrukturen, welche als Datei angesprochen werden konnten. Das Dateisystem konnte deshalb nur mit zwei, fest vorgegebenen "Dateinamen" arbeiten, auf die konnte man dann aber über die "normalen Dateifunktionen" zugreifen. Dies hatte den Vorteil, dass der selbe Sourcecode auch auf einem PC verwendet werden konnte, auf dem µP aber kein aufwändiges Dateisysten programmiert werden musste. Zudem konnte jeder C-Programmierer erkennen, was der Code macht.
Dies gilt scheinbar nur bei dem verwendeten Compiler und den, bzw. die verwendeten Bibliotheken, kenne ich (noch) nicht, da ich bisher nicht mit dem AVR gearbeitet habe.
Zudem gibt es auch noch das Problem der richtigen Reihenfolge, da war der UP auch recht zurückhaltend.
MfG Peter(TOO)
Lesezeichen