strukturen, ein- und ausstieg

[Peter(TOO)]

Hallo Wsk8,

[CODE]
Sorry, aber lern doch bitte wie man die Fehlermeldungen liest. Die sind zu 98% immer sehr genau an der entsprechenden Stelle! Nur bei fehlenden Klammern ist die Meldung verstreut, aber dafür gibts jetzt ja die Möglichkeit sie mit Autocomplete sofort zu schließen.

Da habe ich vermutlich mehr Erfahrung als du!
Ich programmiere jetzt seit 25 Jahren in C, hauptsächlich auf Microcontrollern, also ohne bestehendes Betriebssystem. Betriebssysteme habe ich auch schon ein paar geschriben. Zudem war ich an der Entwicklung mehrerer C-Compiler beteiligt.
Beruflich programmiere ich Microprozessoren seit 1976, anfangs mit einem KIM-1, alles von Hand auf Papier assembliert und Hex eingegeben. War eine heiden Arbeit!
Das waren damals Prüfprogamme, mit denen Hardware in der Fabrikation getestet wurde.

Sollte eigentlich an Erfahrung genügen.

[CODE]
Der Compiler will hinter uint8_t eine Klammer. Warum ist mir jetzt auch nicht bewusst. Evtl liegts am uint8_t.

Das ist mit Garantie so.
Der Compiler kennt uint8_t nicht, also wird es lexikalisch als Bezeichner gewertet. Bei der syntaktischen Prüfung ist dann uint8_t kein Datentyp, muss also eine Variable sein, folglich kann daruf nur ein ",", eine andere Variable oder eine ")" folgen!

Folglöich kennt der Compiler an dieser Stelle uint8_t nicht, dass hast du aber bestritten!

Ich habe nicht immer die Zeit und Lust lange Romane zu schreiben!
Deshalb meine Kurze Bemerkung, dass der Compiler uint8_t nicht kennt und der eigentliche Fehler irgendwo vorher zu suchen ist.

Ich habe es schon zur genüge erlebt, dass in Projeten ein Tippfel in eine HeaderDatei, erst viele Seiten und andere Includes später zu einem Fehler führt.
Jeder der etwas mehr Erfahrung mit C hat, kennt das eben, dass der Fehler zwischen Anfang und der gemeldeten Stelle liegt.
Das hängt halt eben auch mit der Freiheit der Sprache zusammen, je restriktiver eine Sprache ist, umso genauer kann die Syntax-Fehlerstelle angegeben werden.

MfG Peter(TOO)

[Wsk8]

Da habe ich vermutlich mehr Erfahrung als du!
Ich programmiere jetzt seit 25 Jahren in C, hauptsächlich auf Microcontrollern, also ohne bestehendes Betriebssystem. Betriebssysteme habe ich auch schon ein paar geschriben. Zudem war ich an der Entwicklung mehrerer C-Compiler beteiligt.
Beruflich programmiere ich Microprozessoren seit 1976, anfangs mit einem KIM-1, alles von Hand auf Papier assembliert und Hex eingegeben. War eine heiden Arbeit!
Das waren damals Prüfprogamme, mit denen Hardware in der Fabrikation getestet wurde.

Sollte eigentlich an Erfahrung genügen.

Dann frage ich mich aber, welche Compiler du verwendest?! Der GCC, den ich verwende, gibt die Fehler zu 98% sehr genau aus!! Wenns nicht so genau ist, dann liegts im Normalfall daran, dass man ein Semikolon oder eine Klammer vergessen hat. Und bei solchen Fehlern treten meistens sowieso mehrere Fehler auf, da die ganze Struktur nicht passt.

Auch frage ich mich, wie du zu der Ansicht gelangt bist, dass der Fehler wo anders als an der angegebenen Stelle liegt? Der Fehler war nämlich mitten in der Parameterliste und uint8_t ist kein selbstdefinierter Typ wo man mal ein Semikolon etc vergisst.

Folglöich kennt der Compiler an dieser Stelle uint8_t nicht, dass hast du aber bestritten!

Ich habe gar nichts bestritten Dazu kann ich mich sogar selbst zitieren:

Nein, aber Peter hat zumindest schon auf der 2 Seite den Hinweis dazu gegeben, denn aber jeder ignoriert hat weil es ja ein sogenannter "RP6-Experte" aus dem RP6-Forum besser wusste.

Deshalb meine Kurze Bemerkung, dass der Compiler uint8_t nicht kennt und der eigentliche Fehler irgendwo vorher zu suchen ist.

Du musst auch keinen langen Romane schreiben. Die einfachste Antwort war einfach: "#include <stdint.h>"

mfg

[Peter(TOO)]

Hallo,

Der GCC, den ich verwende, gibt die Fehler zu 98% sehr genau aus!!

Meistens trifft der Compiler auch die Stelle, aber:

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.

Auch frage ich mich, wie du zu der Ansicht gelangt bist, dass der Fehler wo anders als an der angegebenen Stelle liegt? Der Fehler war nämlich mitten in der Parameterliste und uint8_t ist kein selbstdefinierter Typ wo man mal ein Semikolon etc vergisst.

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.

Du musst auch keinen langen Romane schreiben. Die einfachste Antwort war einfach: "#include <stdint.h>"

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)

[Wsk8]

Zur Lösung willst du keine 3 Wörter schreiben, aber jetzt schreibst du doch auf einmal nen halben Roman
Besser du machst es das nächste mal gleich am Anfang mit der Lösung, dann können wir uns ein paar Seiten sparen

Und was soll jetzt der Grundkurs in C?? Hab ich alles schon 100x gehört und wer es nicht weis, kann es auch schnell selbst googlen. Das ist keine Kunst, es ist eher eine Schande wenn man es als C-Programmierer nicht weiß.

Da für mich die STL zu C gehört, gehört auch uint8_t für mich dazu! Wie der implementiert ist, ist für mich relativ egal.

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.

Ähm nein?! stdint.h gibts bei eigentlich jedem Compiler. Wenn man portablen Sourcecode erstellen will, sollte man sogar stdint verwenden, da ein integer je nach System anders ist.

mfg