#define?
const!
Geht nicht immer...
Du bist in Begriff, Forum64 zu verlassen, um auf die folgende Adresse weitergeleitet zu werden:
Bitte beachte, dass wir für den Inhalt der Zielseite nicht verantwortlich sind und unsere Datenschutzbestimmungen dort keine Anwendung finden.
letzter Beitrag von sauhund am
#define?
const!
Geht nicht immer...
Geht nicht immer...
Noch einer:
bringt auf C90-Compilern schöne Fehlermeldungen:
const.c(4): Error: Constant integer expression expected
oder:
const.c:4: Warnung: ISO-C90 verbietet Feld »str« variabler Größe
In C99 und C++ geht's aber. Und prinzipiell stimme ich Fröhn auch zu.
Zitatconst int i = 10;
char str[i];
wer sowas macht dem gehört auch der compiler abgenommen
wer sowas macht dem gehört auch der compiler abgenommen
Wenn Du mal zurückblätterst, wirst Du sehen, dass es um const vs. define ging. Und das war ein Beispiel für eine Stelle, wo const nicht weiterhilft. In Sprachen, wo es keinen Präprozessor gibt, ist das aber die einzige sinnvolle Möglichkeit, das zu tun. Und *wenn* ein Compiler das beherrscht (z.B. Constant Propagation), ist das genauso legitim wie inline functions statt macros.
Aber ich drifte vom Thread-Thema ab...
Dummyposting, um die Kursivschrift abzuschalten.
vollständig müsste das so lauten:
ich habe es deshalb so geschrieben, damit man den zusammenhang zu c sehen kann, da:
in c auch gerne so abgekürzt wird:
btw. die klammern um "(PRIM)" sind in basic nicht notwendig ...
... und wieder was dazugelernt. Die Abkürzung in BASIC kannte ich bis vorhin noch nicht...
Die Abkürzung in BASIC kannte ich bis vorhin noch nicht...
um es noch genauer zu schereiben:
also in BASIC gibt es die beiden wahrheitswerte "0"( ~ "false") und "-1" ( ~ "true"), wobei der interpreter IMO alles, was "nicht null" ist, als "true" wertet.
die IF-abfrage prüft deshalb einfach, ob die bedingung - hier die variable PRIM - "nicht null" ist. ein expliziter vergleich mit "<> 0" wäre dann nur doppelt gemoppelt ; )
diese erkenntnisse lassen sich auch in c weiternutzen. nur das dort die beiden wahrheitswerte "0" und "1" sind ...
Aufgabe 1:
Funktionen main und istPrimzahl sind vertauscht
Fehlermeldungen des CC65:
(14): Warning: Function call without a prototype
(32): Error: Conflicting type for 'istPrimzahl'
(34): Error: Undefined symbol: 'n'
Der erste Fehler ist klar. Der Compiler kennt die Funktion nicht, da sie erst nach main kommt.
Die anderen Fehlermeldungen sind mir unklar. In Zeile 32 steht doch nur eine { Funktionsklammer. Und n, wird in 34 als undefined bemängelt, obwohl n ja in 31 definiert wird.
Zitat(14): Warning: Function call without a prototype
...
Der erste Fehler ist klar. Der Compiler kennt die Funktion nicht, da sie erst nach main kommt.
Richtig. Und jetzt kommt das, was auch die anderen Fehlermeldungen (mehr oder weniger) erklärt: Der Compiler "erfindet" die fehlende Funktion und nimmt an, das diese bestimmte Parameter und einen bestimmten Rückgabetyp hat. Obwohl ich jetzt nicht extra nachgesehen habe, vermute ich, dass er "int istPrimzal(unsigned int)" erfindet. Ich schau jetzt auch nicht nach, weil man sich auf so eine Sauerei sowieso nicht verfässt... Diesen erfundenen Funktionsprototyp merkt sich der Compiler in seiner Symboltabelle.
Zitat(32): Error: Conflicting type for 'istPrimzahl'
Hier steht zwar nur eine Klammer, aber der Compiler muss bis zu dieser Klammer "lesen", um das Ende des Funktionskopfs zu erkennen. Die Fehlermeldung bezieht sich also wahrscheinlich nicht auf die Klammer, sondern auf das, was davor steht. Solche Situationen sieht man in C (wahrscheinlich auch bei anderen Sprachen) übrigens oft.
Was stört an dem Funktionskopf? Er stimmt nicht mit der erfundenen Funktion überein. Der Compiler findet "int istPrimzahl(unsigned int)" in seiner Tabelle, jetzt aber "unsigned char istPrimzahl(unsigned int)" im Quelltext. Dieser Unterschied ist ein Fehler.
Zitat(34): Error: Undefined symbol: 'n'
Das ist vermutlich ein Folgefehler der nicht "akzeptierten" Funktion istPrimzahl. Wenn der Compiler einmal richtig schiefhängt, kommen danach oft eine Unmenge Fehlermeldungen, über die man nicht weiter nachdenken sollte. Die erste Fehlermeldung ist oft die wichtigste.
Hilft das?
ZitatDer Compiler "erfindet" die fehlende Funktion und nimmt an, das diese bestimmte Parameter und einen bestimmten Rückgabetyp hat. Obwohl ich jetzt nicht extra nachgesehen habe, vermute ich, dass er "int istPrimzal(unsigned int)" erfindet.
...
Was stört an dem Funktionskopf? Er stimmt nicht mit der erfundenen Funktion überein. Der Compiler findet "int istPrimzahl(unsigned int)" in seiner Tabelle, jetzt aber "unsigned char istPrimzahl(unsigned int)" im Quelltext. Dieser Unterschied ist ein Fehler.
Danke ! Das ist einleuchtend !
ZitatHier steht zwar nur eine Klammer, aber der Compiler muss bis zu dieser Klammer "lesen", um das Ende des Funktionskopfs zu erkennen. Die Fehlermeldung bezieht sich also wahrscheinlich nicht auf die Klammer, sondern auf das, was davor steht. Solche Situationen sieht man in C (wahrscheinlich auch bei anderen Sprachen) übrigens oft.
Das dürfte für die Zukunft auch sehr wichtig zu wissen sein...
ZitatObwohl ich jetzt nicht extra nachgesehen habe, vermute ich, dass er "int istPrimzal(unsigned int)" erfindet.
genau
generell sollte man bei compilerfehlern immer nur den allerersten ernst nehmen (und erstmal beheben), alles was nach dem ersten kommt sind oft folgefehler und teilweise auch totaler quark.