Hallo und guten Tag, habe in einer Headerdatei folgende Definitionen: #define TASTENDRUCK_KEINER 0 #define TASTENDRUCK_GEDRUECKT 1 #define TASTENDRUCK_WIEDERHOLT 2 #define TASTENPHASE_NORMAL 0 #define TASTENPHASE_ENTPRELLEN 1 #define TASTENPHASE_WIEDERHOLT 2 Der Compiler (Atmel Studio 7.0) meldet für die Zeilen in denen die 0 (Null) zugewiesen wir den Fehler: expeted identifier befor numeric constant Was ist bei 0 anders gegenüber der 1 und 2. Gruß Heinz
> Der Compiler (Atmel Studio 7.0) meldet für die Zeilen in denen die 0 > (Null) zugewiesen wir den Fehler [..] Hier wird keine 0 zugewiesen. > Was ist bei 0 anders gegenüber der 1 und 2. Dass Du uns nicht den kompletten Quellcode zeigst.
Hallo Heinz W. schrieb: > #define TASTENDRUCK_KEINER 0 > #define TASTENDRUCK_GEDRUECKT 1 > #define TASTENDRUCK_WIEDERHOLT 2 > #define TASTENPHASE_NORMAL 0 > #define TASTENPHASE_ENTPRELLEN 1 > #define TASTENPHASE_WIEDERHOLT 2 Das ist noch eine Textersatzdefinition, die kein Code erzeugt!
Heinz W. schrieb: > Der Compiler (Atmel Studio 7.0) meldet für die Zeilen in denen die 0 > (Null) > zugewiesen wir den Fehler: expeted identifier befor numeric constant Dann zeige doch bitte die betreffenden Zeilen deines Programms.
Heinz W. schrieb: > expeted identifier befor numeric constant Wenn der Compiler das ausgibt, ist er kaputt. Du solltest ihn löschen und von einer sicheren Quelle erneut installieren. Edit: Ok, im Threadtitel ist es richtig geschrieben. Trotzdem liegt der Fehler nicht in den von dir geposteten Zeilen, sondern woanders.
:
Bearbeitet durch Moderator
Wenn der Compiler bei den oben geposteten 6 Zeilen diesen Fehler expeted identifier befor numeric constant ausgibt, dann ist der Rechner verseucht. Wahrscheinlich hast du dir C-Emotet eingefangen. Als Lösung hilft nur eine vollständige Formatierung des Rechners. Nicht lange warten, bevor er noch andere Rechner mit zerstört.
Du musst im deinem Quellcode an den Verwendungsstellen der defines nachschauen. Dort passiert der Fehler.
Hallo Micha, zum Glück habe ich nicht alle Hinweise berücksichtigt und meinen Rechner sofort formartiert bzw. verschrottet. Ich habe eine lange Lebens- und Berufserfahrung (ich bin Jahrgang 1943)und während dieser Zeit immer wieder festgestellt: Fehler sind trivial. Ich programmiere rein hobbymäßig und allein und benötige manchmal ein Forum um mich "aufzuschlauen". Dein Hinweis war der Treffer. Ich verwende für die Auswertung einer Matrixtastatur einen Zustandsautomat mit Strukturen. Der Fehler lag in der Zuweisung dieser "defines", an den Programmpositionen musste das "=" Zeichen und nicht "->" eingesetzt werden. Nach Änderung fehlerfreie Compilirung. Nochmals vielen Dank für Deinen Hinweis. Gruß Heinz
Der Compiler zeigt bei Syntaxfehlern, in denen Makros eine Rolle spielen, üblicherweise auf zwei Stellen im Quellcode, nämlich dorthin, wo das Makro definiert wurde, und dorthin, wo schließlich der Fehler erkannt wurde. Beispiel:
1 | test.c:1:32: error: expected identifier before numeric constant |
2 | 1 | #define TASTENDRUCK_KEINER 0 |
3 | | ^ |
4 | test.c:9:8: note: in expansion of macro ‘TASTENDRUCK_KEINER’ |
5 | 9 | a -> TASTENDRUCK_KEINER; |
6 | | ^~~~~~~~~~~~~~~~~~ |
Die erste Meldung sagt aus: "Da steht irgendwo eine 0, wo eigentlich etwas anderes stehen sollte, ..." Der Satz ist aber noch nicht zu Ende, sondern wird in der zweiten Meldung fortgesetzt, die besagt: "... und dieses "irgendwo" ist die Zeile 9 in "test.c", wo das fragliche Makro (TASTENDRUCK_KEINER) zu 0 expandiert wird." Wenn du dir also in
1 | a -> TASTENDRUCK_KEINER; |
den Makronamen TASTENDRUCK_KEINER durch 0 ersetzt denkst, steht da:
1 | a -> 0; |
Der "->"-Operator erwartet als linken Operanden einen Zeiger auf ein
Struktur (struct) und als rechten Operanden den Namen eines Elements der
Struktur. In diesem Fall steht da aber kein Name (identifier), sondern
eine Zahl. Und genau diesen Identifier vermisst der Compiler laut seiner
Meldungen.
Auf die Idee, dass die 0 richtig ist und du stattdessen den falschen
Operator ("->" statt "=") verwendet hast, kommt der Compiler leider
nicht. Hier musst du als Programmierer etwas Phantasie beweisen, was du
ja schließlich auch getan hast.
:
Bearbeitet durch Moderator
Hallo Yalo, danke für den Hinweis. Ich bin fürjeden Tip dankbar. Gruß Heinz
Yalu X. schrieb: > Auf die Idee, dass die 0 richtig ist und du stattdessen den falschen > Operator ("->" statt "=") verwendet hast, kommt der Compiler leider > nicht. Das ist das "Schöne" an C-Compilern. Statt auf den naheliegensten Fehler hin zu weisen, kommen tiefgreifende Analysen. Wo ein Turbo Pascal/Delphi ein simples "missing ';'" ausspuckt (und damit in 99.9% der Fälle Recht hat), würde entsprechend ein C-Compiler sonstwelche Konstrukte auffahren, um dem verbleibenden Quelltext doch noch irgend einen Sinn abzugewinnen, aber am End trotzdem gnadenlos zu scheitern (mit ein Fehlermeldung, die es zumindest Einsteigern schwer macht, ihr überhaupt irgend einen Sinn ab zu gewinnen).
my2ct schrieb: > (mit ein Fehlermeldung, die es zumindest Einsteigern schwer > macht, ihr überhaupt irgend einen Sinn ab zu gewinnen). Wer die Hälfte von dem ignoriert, was der Compiler ihm sagt, darf sich nicht beschweren, wenn er die andere Hälfte nicht versteht. Einfach mal die ganze Fehlermeldung lesen.
Nop schrieb: > Einfach mal > die ganze Fehlermeldung lesen. Genau das ist das Problem: Anfänger lesen üblicherweise die Fehlermeldungen gar nicht, oder sie verstehen sie einfach nicht, weil dort natürlich die korrekten Fachtermini benutzt werden, die die Anfänger wieder nicht kennen, oder zu faul sind, diese zu ergründen. Das ist bspw. ein Punkt (Fehlermeldungen lesen), der in jedem mir bekannten Buch / Kurs viel zu kurz kommt. Was auch wiederum verständlich ist, weil die ja wieder Compiler-spezifisch sind.
Heinz W. schrieb: > expeted identifier befor numeric constant Ohne weitere Info kann man da nicht weiterhelfen. Der Compiler gibt Zeilennummern aus, wo der Fehler auftritt. Allerdings gibt es i.d.R. (wesentlich) mehr als 1 Stelle im Code, die man korrigieren könnte, um den Fehler an dieser Stelle zu beheben. Dementsprechend werden Fehler / Warnungen öfter an unerwarteter Stelle ausgegeben, eben weil die Stelle nicht eindeutig ist. Bei Fehlern in / mit Makros kann man sich die präprozessierte Quelle anschauen, da sieht man dann, wie die Makros expandiert wurden — zumindest falls der Fehler nicht vom Präprozessor selber stammt. Manchmal hilft auch, -P -save-temps zu dem Optionen hinzuzufügen. Die präprozessierte Quelle wird dann in einem i-File (C), ii-File (C++) oder s-File (Assembler) gespeichert. -P bewirkt, dass sich die Fehlermeldung nicht auf die C-Quelle bezieht, sondern auf den Code nach dem Präprozessieren, was wiederum das ist, was der eigentliche Compiler schließlich sieht.
:
Bearbeitet durch User
my2ct schrieb: > Yalu X. schrieb: >> Auf die Idee, dass die 0 richtig ist und du stattdessen den falschen >> Operator ("->" statt "=") verwendet hast, kommt der Compiler leider >> nicht. > > Das ist das "Schöne" an C-Compilern. Statt auf den naheliegensten Fehler > hin zu weisen, kommen tiefgreifende Analysen. Du hältst es tatsächlich für den naheliegendsten Fehler, dass jemand "->" statt "=" schreibt? Ich habe diesen Fehler bisher noch nie gesehen, weder bei mir selber noch bei anderen. Du etwa? my2ct schrieb: > Turbo Pascal/Delphi Ja, ja, ich weiß, in Pascal ist immer alles um Welten besser ;-) Wirklich? Schau dir einfach mal folgenden, dem des TE sehr ähnlichen Pascal-Code an:
1 | var i: integer; |
2 | begin |
3 | i . 0 |
4 | end. |
Der Programmierer hat hier versehentlich "." statt ":=" geschrieben. Der FPC sagt dazu:
1 | test.pas(3,7) Error: Illegal qualifier |
2 | test.pas(3,7) Fatal: Syntax error, "identifier" expected but "ordinal const" found |
Und jetzt vergleiche mal die Meldung des Pascal-Compilers
1 | "identifier" expected but "ordinal const" found |
mit der des C-Compilers:
1 | expected identifier before numeric constant |
Ok, sie Satzstellung ist etwas anders ;-) Und unter einer "numeric constant" (numerische Konstante) kann sich ein Anfänger vermutlich sehr viel mehr vorstellen als mit einer "ordinal const" (Ordnungskonst).
:
Bearbeitet durch Moderator
Johann L. schrieb: > Bei Fehlern in / mit Makros kann man sich die präprozessierte Quelle > anschauen, da sieht man dann, wie die Makros expandiert wurden — > zumindest falls der Fehler nicht vom Präprozessor selber stammt. Hinzukommt, dass vielen (Anfängern) gar nicht klar ist, dass der Präprozessor ein nicht-interaktiver Editor ist. Daher auch die unausrottbare Unsitte, funktionsähnliche Macros zu schreiben und sich dann über schräge Ergebnisse zu freuen.
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.