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.
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.
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.
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.
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).
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 abschalten