Hallo zusammen, mir scheint, ich habe ein Missverständnis dazu, wie h-Files in C funktionieren und wie man über sie Funktionen in einem C-File referenziert. Mein Problem ist, ich bekomme die Meldung, die Referenz zu einer Funktion wird nicht gefunden "undefined reference to..." Bin bisher davon ausgegangen, wenn die Inkludierungs-Kette in einem h-File die verwendete Funktion als Deklaration findet und in einem c-File die Definition ist, dass es passt. Des scheint net so Wie müsste ich das gestalten, damit die Funktion GetActivityState() in Message_Dispatcher.c nutzbar ist? vielen Dank :) >Wenn ich In formationen "vorenthalte" liegt es nicht daran, dass ich das mit >Absicht mache sondern, dass ich nicht weiß, dass sie relevant sind.
Angehängte Dateien:
-
undefRefJPG.jpg
250 KB
Du musst die KeyPresser.c natürlich auch noch mit kompilieren und anschließend dazulinken. Zeig mal dein Makefile oder Compiler Anweisung.
:
Bearbeitet durch User
Liegt meist am falschen aufruf von gcc/g++, der Linker findet dann nix. Alle relevanten files mit angeben dann geht es.
Die Header Datei sagt dem Compiler nur, das es eine GetActivityState Funktion gibt, die keine Parameter braucht und ein int zurückgibt. Erst beim Linken ist es erforderlich das die Funktion auch wirklich da ist und darum muss diese auch vorher gebaut (kompiliert) werden. Ich gehe daher davon aus das du die KeyPress.c nicht beim gcc angegeben hast.
Angehängte Dateien:
-
wasCpp.jpg
150 KB
:) der Tip war gut - er war zwar nicht die Ursache, hat mich aber auf das richtige Folder-Click-Quest geschickt. Hab in meiner Cube IDE das make-File gefunden (Ich bin so ein Hacker), das wiederrum auf andere m-Files in den Subdirectories verweist und siehe da - ich hab offenbar eines meiner "C"-Files als cpp File gespeichert und das nicht gemerkt - im Folderbrowser hab ich´s dann gesehen auf der Suche nach den Make-Files :) ba-Dum-Tss Vielen Dank :)
Tim T. schrieb: > Die Header Datei sagt dem Compiler nur, das es eine GetActivityState > Funktion gibt, die keine Parameter braucht und ein int zurückgibt. Schreibt man da nicht normalerweise noch ein "extern" im h-File davor? Ich mache das eigentlich immer so, zumindest in so einer Konstellation abc.h/abc.c . Seit dem ich das so mache gibt es eigentlich keine Probleme mehr. Ich kann mich aber auch noch daran erinnern, das ich mir da manchmal schon einen Wolf gesucht habe, weil er irgend etwas nicht gefunden hat. Ich war früher auch der Meinung, wenn das Ding im h-File angeben ist dann sollte er es auch finden, dem ist aber nicht so. Ist nach meinem Empfinden eben auch so ne unschöne C-Eigenschaft.
Zeno schrieb: > Schreibt man da nicht normalerweise noch ein "extern" im h-File davor? > Ich mache das eigentlich immer so, zumindest in so einer Konstellation > abc.h/abc.c .
1 | 6.2.2 Linkages of identifiers |
2 | [...] |
3 | 5) If the declaration of an identifier for a function has no storage-class specifier, its linkage is determined exactly as if it were declared with the storage-class specifier extern. |
Mombert H. schrieb: > Zeno schrieb: >> Schreibt man da nicht normalerweise noch ein "extern" im h-File davor? >> Ich mache das eigentlich immer so, zumindest in so einer Konstellation >> abc.h/abc.c . > >
1 | > 6.2.2 Linkages of identifiers |
2 | > [...] |
3 | > 5) If the declaration of an identifier for a function has no |
4 | > storage-class specifier, its linkage is determined exactly as if it were |
5 | > declared with the storage-class specifier extern. |
6 | > |
Danke, genau das war ich gerade als Begründung am suchen.
Mombert H. schrieb: > If the declaration of an identifier for a function has no storage-class > specifier... Nun gerade bei C gibt es einen Haufen an Defaults, was der offenbar angeborenen Schlampigkeit von C-Programmierer Vorschub leistet. Dazu kommt noch, daß viele Leute meinen, nicht ohne eine IDE auszukommen. Im Ergebnis wissen sie dann nicht, wie sie die eigentliche Toolchain aufrufen müssen und welche Quelldateien tatsächlich für ein Projekt übersetzt werden müssen und wo die dabei erzeugten Objektdateien stehen müssen, damit der Linker sie dann auch findet. OK, der GCC benimmt sich da besonders zickig - aber das nur am Rande. Grundsätzlich sollte man sich aber merken, daß das Inkludieren von Dateien (gleich welcher Bezeichnung bzw. Extension) in eine Quelldatei lediglich eine reine Text-Operation ist, die vor dem eigentlichen Übersetzen stattfindet. Von daher sehe ich es als eine konsequente und saubere Sache an, sich nicht auf solche o.g. Defaults zu verlassen, sondern stattdessen "extern" vor Dinge zu schreiben, die auch tatsächlich extern sind - auch wenn das mal nicht wirklich notwendig ist. W.S.
W.S. schrieb: > Nun gerade bei C gibt es einen Haufen an Defaults, was der offenbar > angeborenen Schlampigkeit von C-Programmierer Vorschub leistet. Wolltest du damit alle C-Programmierer beleidigen, oder warst du nur zu schlampig, dich besser auszudrücken?
^^zum Glück ist mein Problem schon gelöst - jetzt kann ich Popcorn machen und dem Thread beim entgleisen zu schauen :)
W.S. schrieb: > Von daher sehe ich es als eine konsequente und > saubere Sache an, sich nicht auf solche o.g. Defaults zu verlassen, Wenn du dich nicht auf den Standard verlassen kannst, brauchst du erst gar nicht anfangen.
Dirk B. schrieb: > W.S. schrieb: >> Von daher sehe ich es als eine konsequente und >> saubere Sache an, sich nicht auf solche o.g. Defaults zu verlassen, > > Wenn du dich nicht auf den Standard verlassen kannst, brauchst du erst > gar nicht anfangen. Diese Diskussion mit W.S. ist sinnlos. Der hat irgendwann im letzten Jahrtausend traumatischen Erlebnisse mit C gehabt, und sich davon nie mehr erholt. Oliver
Dirk B. schrieb: > W.S. schrieb: >> Von daher sehe ich es als eine konsequente und >> saubere Sache an, sich nicht auf solche o.g. Defaults zu verlassen, > > Wenn du dich nicht auf den Standard verlassen kannst, brauchst du erst > gar nicht anfangen. Er hat hier schon öfters vom Standard zugesicherte Eigenschaften der Sprache genannt, auf die er sich nicht verlassen will. Das liegt aber nicht daran, dass sie nicht zuverlässig wären, sondern eher daran, dass er sie halt nicht mag oder nicht richtig verstanden hat.
Rolf M. schrieb: > Das liegt aber nicht daran, dass sie nicht zuverlässig wären, sondern dass Pascal da pingeliger ist. In C können unnötige Dinge weggelassen werden. So wie in natürlicher Sprache üblich.
A. S. schrieb: > In C können unnötige Dinge weggelassen > werden. So wie in natürlicher Sprache üblich. Und kommt dann am Ende Gendern raus - nein danke. Ich hatte Anfangs auch das "extern" weg gelassen und das hat eben mal funktioniert und ein anderes Mal eben nicht. Kann ja sein das vom benutzten Compiler, Linker, IDE what ever abhängig ist - ich habe das nicht näher untersucht -, aber es zeigt eben das die Defaults offenbar eben nicht generell allgemein gültig sind. Deshalb habe ich es mir angwewöhnt eben das "extern" generell davor zu schreiben. Das Eintippen der 6 Zeichen geht allemal schneller als die Fehlersuche oder in irgendeinem Forum nachzufragen warum der Compiler-/Linkerlauf nicht funktioniert. A. S. schrieb: > dass Pascal da pingeliger ist. Und das ist auch gut so.
Zeno schrieb: > aber es zeigt eben das die Defaults offenbar > eben nicht generell allgemein gültig sind. Nein. Wenn du in C programmierst, dann sind die gültig. Wenn du einen Compiler benutzt, der für so etwa wie "so was ähnliches wie C" gedacht ist, dann programmierst du in "so etwas ähnlichem wie C". Da gelten dann andere Regeln, die man dort natürlich beachten sollte. Das hat mit C dann nichts zu tun, und Regeln für "so etwas ähnliches wie C" auf C zu übertragen ist schlicht Unsinn. Oliver
Zeno schrieb: > Deshalb habe ich es mir > angwewöhnt eben das "extern" generell davor zu schreiben. Das Eintippen > der 6 Zeichen geht allemal schneller als die Fehlersuche oder in > irgendeinem Forum nachzufragen warum der Compiler-/Linkerlauf nicht > funktioniert. Man könnte auch einfach die Sprache lernen, die man benutzt. Aber ich weiß, das ist zu viel verlangt.
Zeno schrieb: > A. S. schrieb: >> In C können unnötige Dinge weggelassen >> werden. So wie in natürlicher Sprache üblich. > Und kommt dann am Ende Gendern raus - nein danke. Da werden unnötige Sachen aber nicht weggelassen, sondern hinzugefügt. > Ich hatte Anfangs auch das "extern" weg gelassen und das hat eben mal > funktioniert und ein anderes Mal eben nicht. Bei Funktionsdeklarationen kann man das extern immer weglassen. Ein Compiler, bei dem das nicht so ist, ist kaputt.
Oliver S. schrieb: > Nein. Wenn du in C programmierst, dann sind die gültig. Wenn du einen > Compiler benutzt, der für so etwa wie "so was ähnliches wie C" gedacht > ist, dann programmierst du in "so etwas ähnlichem wie C". Da gelten dann > andere Regeln, die man dort natürlich beachten sollte. Das hat mit C > dann nichts zu tun, und Regeln für "so etwas ähnliches wie C" auf C zu > übertragen ist schlicht Unsinn. Rolf M. schrieb: > Bei Funktionsdeklarationen kann man das extern immer weglassen. Ein > Compiler, bei dem das nicht so ist, ist kaputt. Dummerweise wußten das die Compiler nicht, daß es C und C gibt. Ist mir letztendlich auch egal. Ich werde das auch nicht weiter verifizieren, da ich C eh nur nutze, wenn kein Weg daran vorbei führt, z.B. µC-Programmierung. Für die paar Projekte tippe ich dann lieber das "extern" ein, auch wenn es nicht nötig ist.
Zeno schrieb: > Dummerweise wußten das die Compiler nicht, daß es C und C gibt. Ist mir > letztendlich auch egal. Ich werde das auch nicht weiter verifizieren, da > ich C eh nur nutze, wenn kein Weg daran vorbei führt, z.B. > µC-Programmierung. Für die paar Projekte tippe ich dann lieber das > "extern" ein, auch wenn es nicht nötig ist. Dann nenn doch mal ein paar Beispiele, wo das tatsächlich aufgetreten ist.
Rolf M. schrieb: > Bei Funktionsdeklarationen kann man das extern immer weglassen. Ein > Compiler, bei dem das nicht so ist, ist kaputt. Wir sind Menschen und keine Maschinen. Und wenn man ein Default-Verhalten nicht benutzt, dann ist das kein Fehler. Stattdessen schafft man dabei eine bessere Lesbarkeit (für den menschlichen Leser, dem Compiler ist es eher egal). Hier laufen mal wieder Leute zur Höchstform auf, die offenbar jegliches Nichtbenutzen von C-Features als üble Fehler ansehen. Ich sehe so etwas ganz anders. Beispiel: Wir hatten hier schon so einige Fälle, wo Leute sich drüber gewundert hatten, als sie uninitialisierte lokale Variablen benutzten, wo es doch heißt, daß man selbstverständlich anzunehmen hat, daß vor dem Starten eines C-Programms der Speicher (RAM) abgelöscht wird. Tja, wenn man die Zusatzweisheit vergessen hat, daß das bei Speicher auf dem Stack nicht so unbedingt gilt, dann kracht es eben und all die Leute, die derart sorglos in C schreiben, hätten die Alternative, sich eben auch alle Zusatzbedingungen zu irgendwelchen Defaults gut zu merken und zu befolgen oder es eben krachen zu lassen. W.S.
W.S. schrieb: > wo es doch heißt, daß man selbstverständlich anzunehmen > hat, daß vor dem Starten eines C-Programms der Speicher (RAM) abgelöscht > wird. C ist halt nichts für Leute, die nach Gerüchten arbeiten.
W.S. schrieb: > Rolf M. schrieb: >> Bei Funktionsdeklarationen kann man das extern immer weglassen. Ein >> Compiler, bei dem das nicht so ist, ist kaputt. > > Wir sind Menschen und keine Maschinen. Und wenn man ein > Default-Verhalten nicht benutzt, dann ist das kein Fehler. Das stimmt. Aber ich schreibe trotzdem z.B. einfach "long" und nicht "signed long int" und verlasse mich auf das implizite "int" und das implizite "signed". Ich schreibe auch nicht vor jede nicht-statische lokale Variable "auto" davor, obwohl das das extra nur dafür vorgesehene Schlüsselwort ist. Und genauso halte ich das mit dem "extern" bei Funktions-Deklarationen. > Stattdessen schafft man dabei eine bessere Lesbarkeit (für den > menschlichen Leser, dem Compiler ist es eher egal). Eine Funktionsdeklaration ist auch ohne das "extern" sofort als solche zu erkennen, weil sie keinen Funktionskörper hat. Bezüglich der Lesbarkeit macht das daher überhaupt keinen Unterschied. > Hier laufen mal wieder Leute zur Höchstform auf, die offenbar jegliches > Nichtbenutzen von C-Features als üble Fehler ansehen. Es wirkt auf mich genau umgekehrt: Du scheinst die Nutzung jeglicher Features von C, die du irgendwie vermeiden kannst, auch zwanghaft zu vermeiden. > Ich sehe so etwas ganz anders. Beispiel: Wir hatten hier schon so einige > Fälle, wo Leute sich drüber gewundert hatten, als sie uninitialisierte > lokale Variablen benutzten, wo es doch heißt, daß man selbstverständlich > anzunehmen hat, daß vor dem Starten eines C-Programms der Speicher (RAM) > abgelöscht wird. Ich weiß nicht, wo es das angeblich heißen soll, aber das ist nicht das Resultat daraus, dass man sich auf ein Sprachfeature nicht verlassen könnte, sondern aus fehlendem Wissen. C hat für solche Variablen noch nie eine implizite Initialisierung vorgesehen. Abgesehen davon warnen Compiler da auch. Es ist also genau genommen ein Resultat aus der Kombination aus fehlendem Wissen mit dem Ignorieren von Warnungen.
:
Bearbeitet durch User
Mombert H. schrieb: > Dann nenn doch mal ein paar Beispiele, wo das tatsächlich aufgetreten > ist. Was ist an Zeno schrieb: > Ich werde das auch nicht weiter verifizieren so schwer zu verstehen? Ich hatte geschrieben das mir das Anfangs passiert ist, jetzt tippe ich die magischen Charakter ein und damit ist für mich das Problem behoben - Punkt.
Zeno schrieb: > Mombert H. schrieb: >> Dann nenn doch mal ein paar Beispiele, wo das tatsächlich aufgetreten >> ist. > Was ist an > Zeno schrieb: >> Ich werde das auch nicht weiter verifizieren > so schwer zu verstehen? Ich hatte geschrieben das mir das Anfangs > passiert ist, jetzt tippe ich die magischen Charakter ein und damit ist > für mich das Problem behoben - Punkt. Dann gehe ich weiter davon aus, dass es nie so passiert ist wie du behauptest ;-)
Zeno schrieb: > Ich hatte geschrieben das mir das Anfangs > passiert ist, jetzt tippe ich die magischen Charakter ein und damit ist > für mich das Problem behoben - Punkt. Es spricht nichts gegen Cargo-Kult. Ich kannte einen, der schrieb immer einen else-Block hinter ein if, weil "manche Compiler das sonst wegoptimieren". Ich verstehe, wenn jemand ein System aus Bezeichnern, Kommentaren, Leerzeilen etc. lebt, wo extern vor Funktionen für sein Layout, seine IDE, seinen Programmierstil sinnvoll ist. Man sollte aber Anfängern nicht suggerieren, die Dinge, die man nicht verstanden hat, seien kaputt.
Mombert H. schrieb: > Dann gehe ich weiter davon aus, dass es nie so passiert ist wie du > behauptest ;-) Wovon Du aus gehst, ist mir völlig Rille. Meinetwegen darf für Dich die Erde auch ne Scheibe sein. A. S. schrieb: > Man sollte aber Anfängern nicht suggerieren, die Dinge, die man nicht > verstanden hat, seien kaputt. Wo habe ich das suggeriert?
Zeno schrieb: > A. S. schrieb: >> Man sollte aber Anfängern nicht suggerieren, die Dinge, die man nicht >> verstanden hat, seien kaputt. > Wo habe ich das suggeriert? Zeno schrieb: > A. S. schrieb: >> In C können unnötige Dinge weggelassen >> werden. So wie in natürlicher Sprache üblich. > [...] > > Ich hatte Anfangs auch das "extern" weg gelassen und das hat eben mal > funktioniert und ein anderes Mal eben nicht. > [...] aber es zeigt eben das die Defaults offenbar > eben nicht generell allgemein gültig sind.
Rolf M. schrieb: > Und genauso halte ich das mit dem "extern" bei > Funktions-Deklarationen. Ähem - nein. Der Grund liegt nicht darin, daß man das 'extern' bei Funktionen weglassen kann, sondern darin, daß man es bei externen Variablen eben NICHT weglassen darf. Sonst gibt es in jedem Objektfile eine derartige Variable und der Linker brüllt einen an. Auch das hatten wir hier in diesem Forum schon. Als leicht zu merkende einfache Konsequenz ist das generelle Dazuschreiben von 'extern' bei beidem, also bei Daten und Funktionen. Das ist viel leichter zu erlernen als das Auseinanderhalten und es stört den Compiler überhaupt nicht. Genau so ist die Regel, bei Variablen erst dann einen sinnvollen Inhalt zu erwarten, nachdem man sie wenigstens einmal beschrieben hat. Auch das begreift und merkt sich leichter als das Auseinanderhalten von lokalen und globalen Variablen. Und auch dazu hatten wir hier schon einen Thread. Das ist also kein exotisches Thema, sondern auch eine recht häufige Falle für Anfänger bzw. Leute, die nur gelegentlich in C programmieren. Ich geb dir mal nen Tip: schreibe einfach mal eine einfache Funktionalität in VHDL oder Verilog. Wenn du das nicht ohnehin öfters machst, dann stehen die Chancen gut, daß du dabei einen Sack voll Anfängerfehlern machst. Und all die Leute, die sowas täglich machen sagen dir "aber sowas weiß man doch!" W.S.
Rolf M. schrieb: > Eine Funktionsdeklaration ist auch ohne das "extern" sofort als solche > zu erkennen, weil sie keinen Funktionskörper hat. Bezüglich der > Lesbarkeit macht das daher überhaupt keinen Unterschied. Ach nö. Bei einem davorstehenden 'extern' darf man erwarten, daß die Funktion in einer anderen Quelldatei steht. Steht da nix, dann kann man erwarten, besagte Funktion in der aktuellen Quelle weiter unten zu finden. Das unterscheiden zu können oder nicht, ist ein durchaus merkbarer Unterschied in der Lesbarkeit. W.S.
Oliver S. schrieb: > Nein. Wenn du in C programmierst, dann sind die gültig. Na klar, mit Ausnahmen und Ausnahmen von den Ausnahmen sozusagen. Will sagen, daß man da bei C einen Haufen Regeln erlernen muß - und daß diese zum großen Teil überflüssig hätten sein können, wenn C in sich logischer aufgebaut wäre. Mal ne Frage: Kennst du ALLE Vorrangregeln von C und weißt du diese auch zu unterscheiden von denen anderer Programmiersprachen? So, daß du in Ausdrücken auf jegliche Klammern verzichten kannst? Das zugrundeliegende Problem ist größer als gedacht: Bei allem, was man an einem Rechner tun kann, sind ähnliche Dinge bei verschiedenen Programmen oftmals unterschiedlich gelöst. Wenn nun jemand öfters zwischen verschiedenen Programmen hin und her wechseln muß, dann braucht er zum Arbeiten eher Programme, in die man sich leichter wieder hineinfinden kann als solche, die ein Mehr an zu Merkendem erfordern. Sonst ist das Umschwenken mühsamer als nötig. Das betrifft eben nicht nur das Schreiben von Programmquellen, sondern alles - selbst der Brief an die Omi, wenn man dabei zwischen verschiedenen Office-Paketen wechseln muß. Nur extrem einseitig eingeübte Leute, die wirklich nix anderes als immer wieder nur eine Tätigkeit mit nur einem einzigen Programm ausüben, sehen das nicht. W.S.
W.S. schrieb: > Na klar, mit Ausnahmen und Ausnahmen von den Ausnahmen sozusagen. Will > sagen, daß man da bei C einen Haufen Regeln erlernen muß - und daß diese > zum großen Teil überflüssig hätten sein können, wenn C in sich logischer > aufgebaut wäre. Was wieder dein eigentliches Problem zeigt. Miemand zwingt dich, C zu verwenden. Ja, die Sprache ist an vielen Ecken furchtbar, und schleppt einen Haufen Altlasten mit sich herum. Das ändert aber nichts daran, daß man eine Programmiersprache kennen muß, wenn man sie ernsthaft benutzen will. Ansonsten sollte man schlicht die Finger davon lassen. Der Spruch "Echte Programmierer können FORTRAN in jeder Sprache schreiben" heisst bei dir halt "Ein W.S. kann PASCAL in jeder Sprache schreiben", aber sowohl der eine als auch der andere können eben eins nicht: in C programmieren. Das ist an sich nichts schlimmes, nur muß man das doch nicht immer auch noch deutlich zeigen. Oliver
:
Bearbeitet durch User
W.S. schrieb: > Ach nö. Bei einem davorstehenden 'extern' darf man erwarten, daß die > Funktion in einer anderen Quelldatei steht. Steht da nix, dann kann man > erwarten, besagte Funktion in der aktuellen Quelle weiter unten zu > finden. Das unterscheiden zu können oder nicht, ist ein durchaus > merkbarer Unterschied in der Lesbarkeit. Das deutet darauf hin, dass du nicht weißt was extern macht. Entweder du schreibst extern vor jede Funktion oder keine, alles andere ist inkonsequent.
W.S. schrieb: > Ach nö. Bei einem davorstehenden 'extern' darf man erwarten, daß die > Funktion in einer anderen Quelldatei steht. Neee... Sie kann in einer anderen Datei stehen, kann aber auch in derselben noch kommen. Ebenso wie man eine als extern deklarierte Variable trotzdem noch in derselben Datei definieren kann. "extern" heißt also eher "möglicherweise extern".
Klaus W. schrieb: > "extern" heißt also eher "möglicherweise extern". Nein! extern heißt "jeder kann mich von extern sehen".
Mombert H. schrieb: > Klaus W. schrieb: >> "extern" heißt also eher "möglicherweise extern". > Nein! extern heißt "jeder kann mich von extern sehen". Das geht auch ohne extern, solange man nicht static davor schreibt.
Klaus W. schrieb: > Mombert H. schrieb: >> Klaus W. schrieb: >>> "extern" heißt also eher "möglicherweise extern". >> Nein! extern heißt "jeder kann mich von extern sehen". > > Das geht auch ohne extern, solange man nicht static davor schreibt. Aber nur weil das extern immer implizit da steht ;-). Aber das ist die Bedeutung von extern bei der Deklaration eine Funktion. Es beschreibt von wo diese Funktion gefunden werden kann, nicht wo man sie findet. Genauso wie static bedeutet, dass diese Funktion nur in dieser translation unit gefunden werden kann.
Mombert H. schrieb: > Aber das ist die > Bedeutung von extern bei der Deklaration eine Funktion. Es beschreibt > von wo diese Funktion gefunden werden kann, Es sagt nur aus, dass sie nicht hier (Zeile) definiert ist.
W.S. schrieb: > Bei einem davorstehenden 'extern' darf man erwarten, daß die > Funktion in einer anderen Quelldatei steht. Die meisten Funktionsdeklarationen stehen in Header-Dateien. Da hat Code nichts zu suchen. Und daher bringt ein extern keinen Informationsgewinn.
W.S. schrieb: > Der Grund liegt nicht darin, daß man das 'extern' bei Funktionen > weglassen kann, sondern darin, daß man es bei externen Variablen eben > NICHT weglassen darf. Das liegt daran, dass es keine andere Möglichkeit gibt, bei Variablen zwischen einer extern-Deklaration und einer Defintion zu unterscheiden. Bei Funktionen dagegen ist diese Unterscheidung auf Grund des bei der Deklaration nicht vorhandenen Funktionskörpers gegeben. Ich gebe dir in sofern recht, als das das eine gewisse Inkonsistenz zwischen Funktionen und Variablen darstellt. > Als leicht zu merkende einfache Konsequenz ist das generelle > Dazuschreiben von 'extern' bei beidem, also bei Daten und Funktionen. Wenn du es bei Funktionen davor schreibst, hilft dir das bei den Variablen nicht. > Das ist viel leichter zu erlernen als das Auseinanderhalten und es stört > den Compiler überhaupt nicht. Naja, "viel" halte ich für übertrieben. Was man nur zusätzlich wissen muss, ist, dass man das "extern" bei Funktionen weglassen kann. Und man muss das sowieso lernen, weil man auch mit fremdem Code in Berührung kommt, und sei es nur in irgendwelchen Beispielen oder Tutorials. Da so gut wie niemand bei den Funktionen ein extern davor schreibt, ist das Wissen, dass man es dort weglassen kann, also eh erforderlich. > Genau so ist die Regel, bei Variablen erst dann einen sinnvollen Inhalt > zu erwarten, nachdem man sie wenigstens einmal beschrieben hat. Auch das > begreift und merkt sich leichter als das Auseinanderhalten von lokalen > und globalen Variablen. Ich habe nichts dagegen, wenn jemand alle globalen Variablen explizit initialisiert. > Ich geb dir mal nen Tip: schreibe einfach mal eine einfache > Funktionalität in VHDL oder Verilog. Wenn du das nicht ohnehin öfters > machst, dann stehen die Chancen gut, daß du dabei einen Sack voll > Anfängerfehlern machst. Und all die Leute, die sowas täglich machen > sagen dir "aber sowas weiß man doch!" Eine Programmiersprache ist ein komplexes Werkzeug. Das muss man eben beherrschen, um damit umzugehen. Und C ist nicht unbedingt für den Gelegenheitsprogrammierer gedacht. W.S. schrieb: > Bei einem davorstehenden 'extern' darf man erwarten, daß die Funktion in > einer anderen Quelldatei steht. Steht da nix, dann kann man erwarten, > besagte Funktion in der aktuellen Quelle weiter unten zu finden. Wenn man das erwartet, liegt das ebenfalls an fehlendem Wissen. Alles auf globaler Ebene, wo nicht explizit static davor steht, hat external linkage. Das gilt übrigens auch für Variablen. Das lernt man sowieso, wenn man die Bedeutung von static kennen lernt. Im Prinzip ist "extern" eigentlich das falsche Wort, denn es führt nicht dazu, dass etwas external linkage hat (das hat es ja sowieso), sondern dazu, dass es keine Definition, sondern nur eine Deklaration ist.
:
Bearbeitet durch User
Dirk B. schrieb: > Die meisten Funktionsdeklarationen stehen in Header-Dateien. Ja, aber nicht alle. Als jemand, der seine .c-Dateien normalerweise so aufbaut, daß öffentlich sichtbare Funktionen über static-Funktionen stehen (weil meist wichtiger für das gesamte Projekt, als irgendwelche static-Helferlein) braucht's über den öffentlichen Funktionen halt für das static-Geraffel weite runten die Prototypen. Sonst klappt es nicht. Klar, könnte man durch eine andere Reihenfolge umgehen, aber wenn die wichtigste Funktion der C-Datei irgendwo bei Zeile 4302 beginnt, finde ich das eben unhandlich. ;-) Nochtsdestotrotz haben die Funktionsdeklarationen bei mir nie "extern" davor stehen, egal wo sie auftauchen. > Da hat Code nichts zu suchen. Absolut. Das h in "Code" steht ja nicht umsonst für die Menge an Code (im Sinne von Code, der ausführbares Ergebnis liefert), die in die .h-Datei kommt. > Und daher bringt ein extern keinen Informationsgewinn. Mich irritiert extern vor Funktionsdeklarationen in Headern auch. Und das, obwohl ich bei Variablen sehr pingelig bin. Ein "unsigned" alleine wird man bei mir nicht finden. Allerdings gehöre ich zu den Leuten, die auch kein schnödes "int" verwenden, sondern grundsätzlich die stdint-Typen. In der Embedded-Welt ist ein Überblick über die Größe der Variablen allerdings auch wichtiger als bei denen, die für den PC entwickeln.
Dirk B. schrieb: > Mombert H. schrieb: >> Aber das ist die >> Bedeutung von extern bei der Deklaration eine Funktion. Es beschreibt >> von wo diese Funktion gefunden werden kann, > > Es sagt nur aus, dass sie nicht hier (Zeile) definiert ist. Nein! extern kann auch vor einer Definition stehen. Rolf M. schrieb: > W.S. schrieb: >> Der Grund liegt nicht darin, daß man das 'extern' bei Funktionen >> weglassen kann, sondern darin, daß man es bei externen Variablen eben >> NICHT weglassen darf. > > Das liegt daran, dass es keine andere Möglichkeit gibt, bei Variablen > zwischen einer extern-Deklaration und einer Defintion zu unterscheiden. Auch dafür ist extern nicht wirklich geeignet, da man auch extern vor die Definition einer Variable schreiben kann ;-)
Nachdenklicher schrieb: > Dirk B. schrieb: >> Die meisten Funktionsdeklarationen stehen in Header-Dateien. > > Ja, aber nicht alle. Als jemand, der seine .c-Dateien normalerweise so > aufbaut, daß öffentlich sichtbare Funktionen über static-Funktionen > stehen Dann sollte da aber auch ein static stehen und diese Dekalrationen bekommen die Wenigsten zu sehen.
Rolf M. schrieb: > Eine Programmiersprache ist ein komplexes Werkzeug. Das muss man eben > beherrschen, um damit umzugehen. Und C ist nicht unbedingt für den > Gelegenheitsprogrammierer gedacht. Wer ist ein Gelegenheitsprogrammierer? Eigentlich wollte ich vermeiden, persönliches hier auszubreiten. Aber wenn jemand wie ich Geräte entwickelt, dann hat er mit weitaus mehr als nur mit Programmierung im allgemeinen und C-Programierung im speziellen zu tun. Folglich ist jeder Entwicklungsingenieur in deinem Sinne nur ein Gelegenheitsprogrammierer - oder? Im Grunde ist es mir wurscht, für WEN damals K&R ihre Weiterentwicklung von BCPL namens C gemacht hatten. Ich gebrauche diese Programmiersprache, um Mikrocontroller mit Firmware zu versehen. Und das funktioniert. Punkt. Und wenn ich mich hier in diesem Forum umsehe, dann muß ich sehen, daß ganz viele Leute zwar C benutzen, aber tonnenweise Fehler begehen, die man eigentlich mit ein wenig logischem Denken nicht gemacht hätte. Bei arg vielen vermisse ich sogar Grundkenntnisse über die Architektur von Mikrocontrollern. Und nun kommst du mit der Ansicht, daß man all die tausende von Wenn-Aber's bei C auswendig kennen soll. Das ist mir zu engstirnig. Auf solche Ideen kommt man nur, wenn man beruflich rein garnix anderes macht, also reiner C-Spezialprogrammierer ist, dem bereits die Architektur des Rechners, den er gerade programmiert, terra incognita ist. Auch Programmiersprachen sollen dem Menschen dienen und nicht umgekehrt. Hier wurde auch über rein gestalterische Dinge diskutiert wie z.B. Formatierungen von Quelltexten. Auch dies ist dem Compiler schnurz. Es dient genauso wie das 'extern' bei Funktionen der menschlichen Lesbarkeit. W.S.
Mombert H. schrieb: >> Das liegt daran, dass es keine andere Möglichkeit gibt, bei Variablen >> zwischen einer extern-Deklaration und einer Defintion zu unterscheiden. > Auch dafür ist extern nicht wirklich geeignet, da man auch extern vor > die Definition einer Variable schreiben kann ;-) Was man alles kann... Nein, hier wird offenbar verzweifelt nach Argumenten gesucht, die beweisen sollen, daß die Ausnahme von der Ausnahme notwendig sei. Nö, ist sie nicht. Man kann es auch anders tun. Schlußendlich haben wir es damit zu tun, daß C kein wirkliches Modulsystem kennt. Damit sind all die Dinge, die zum sinnvollen Ordnen in einem Projekt nötig wären, in C nicht machbar. Nachbesserungen wie 'static' und Konsorten schaffen zwar eine gewisse Erleichterung, sind aber kein richtiger Ersatz für eine geregelte Kapselung durch ein sauberes Modulsystem. Und was für einen albernen Kruscht das Einführen von neuen Schlüsselwörtern in C nach sich zieht, haben wir ja bei 'weak' sehen dürfen. Sämtliche Backpfeifen, die weder das Interruptsystem der Cortex-Architekturen noch den eigentlichen Zweck von 'weak' kapiert haben, meinten, daß das ein neues Spielzeug in C sei. W.S.
W.S. schrieb: > Rolf M. schrieb: >> Eine Programmiersprache ist ein komplexes Werkzeug. Das muss man eben >> beherrschen, um damit umzugehen. Und C ist nicht unbedingt für den >> Gelegenheitsprogrammierer gedacht. > Wer ist ein Gelegenheitsprogrammierer? > Eigentlich wollte ich vermeiden, persönliches hier auszubreiten. Aber > wenn jemand wie ich Geräte entwickelt, dann hat er mit weitaus mehr als > nur mit Programmierung im allgemeinen und C-Programierung im speziellen > zu tun. Folglich ist jeder Entwicklungsingenieur in deinem Sinne nur > ein Gelegenheitsprogrammierer - oder? Ja und wo ist dein Problem? Wenn sie ein Werkzeug einsetzen, sollten sie das Werkzeug kennen, oder sich wenigstens nicht beschweren, wenn sie Fehler machen, weil sie es nicht kennen. Das gilt für Programmiersprachen wie für alle anderen Werkzeuge wie CAD-Programme oder eine Kreissäge.
W.S. schrieb: > Mombert H. schrieb: >>> Das liegt daran, dass es keine andere Möglichkeit gibt, bei Variablen >>> zwischen einer extern-Deklaration und einer Defintion zu unterscheiden. >> Auch dafür ist extern nicht wirklich geeignet, da man auch extern vor >> die Definition einer Variable schreiben kann ;-) > > Was man alles kann... > Nein, hier wird offenbar verzweifelt nach Argumenten gesucht, die > beweisen sollen, daß die Ausnahme von der Ausnahme notwendig sei. Du solltest wirklich einmal nachlesen, was extern tatsächlich bedeutet. Dann könntest du einschätzen, was eine Ausnahme ist und was die Regel.
W.S. schrieb: > Und nun kommst du mit der Ansicht, daß man all die tausende von > Wenn-Aber's bei C auswendig kennen soll. Das wäre der Idealfall, aber den erfüllen nur wenige. Die Fälle, die du hier immer wieder anbringst, (alle Variablen immer initialisieren, weil du dir nicht merken kannst, welche per default initialisiert werden, und welche nicht, und ähnliches) sind im schlechtesten Fall unsinniger Cargo-Kult, im besten Fall dein persönlicher Programmierstil. Ersteres sollte man schlicht lassen, über zweiteres kann man diskutieren, muß man aber nicht. Du kannst machen, was immer du willst, aber hör auf, das als allein seligmachende Weisheiten zu verkaufen. Und das gilt auch für den Fall, daß du aus was für Gründen auch immer mit nicht standardkonformen Compilern und defekten Linkerscripten arbeiten musst. Ich kenne sowas aus meiner Studienzeit auch, aber das war im letzten Jahrtausend, und zwar deutlich. Oliver
:
Bearbeitet durch User
Dirk B. schrieb: > Dann sollte da aber auch ein static stehen und diese Dekalrationen > bekommen die Wenigsten zu sehen. Steht da. So wie sich das gehört. :-)
Oliver S. schrieb: > Und das gilt auch für den Fall, daß du aus was für Gründen auch immer > mit nicht standardkonformen Compilern und defekten Linkerscripten > arbeiten musst. Noch einer, der das Stänkern nicht bleiben lassen kann. Also: ich arbeite OHNE Linkerscripte und MIT dem Keil bei Arm sowie mit dem zu Softune gehörigen Compiler für die FR und früher mit dem IAR für die 78k3/4. Und nicht mit dem GCC. Das hatte ich mal bei der Lernbetty gemacht und mache seitdem aufgrund der damit gemachten Erfahrungen einen großen Bogen um den GCC. Und wenn du nix anderes kennst als den GCC dann ist mir deine Ansicht zu schmal um weiter drüber zu diskutieren. Und wenn du keine sachlichen Argumente mehr hast, dann werde du mal nicht persönlich. Das ist kein guter Stil. W.S.
W.S. schrieb: > ich > arbeite OHNE Linkerscripte und MIT dem Keil bei Arm Über diese Aussage müsstest du dann doch nochmal nachdenken. Oliver
C/C++ sind komplex und man weiß sicher nicht alles, auch wenn man die Sprachen schon lange benutzt. Aber wenn man etwas am Standard vorbeiprogrammiert nur weil es ja auch funktioniert, und dann statt das zu korrigieren einfach nur schön redet, dann geht mir sowas auch gegen den Strich. Ich habe lange in so einer Inselwelt programmiert, hat alles erfolgreich funktioniert, aber es erschwert den Blick über den Tellerand oder gar Werkzeuge zu benutzen die der Rest der Welt benutzt. Also besser an den Standard halten als irgendwelchen Predigern zu folgen.
W.S. schrieb: > Rolf M. schrieb: >> Eine Programmiersprache ist ein komplexes Werkzeug. Das muss man eben >> beherrschen, um damit umzugehen. Und C ist nicht unbedingt für den >> Gelegenheitsprogrammierer gedacht. > > Wer ist ein Gelegenheitsprogrammierer? Ich hatte auf folgende Aussage von dir geantwortet: > Wenn du das nicht ohnehin öfters machst, dann stehen die Chancen gut, daß > du dabei einen Sack voll Anfängerfehlern machst. Und all die Leute, die > sowas täglich machen sagen dir "aber sowas weiß man doch!" Und jemand, der das "nicht ohnehin öfters" macht, ist eben jemand, der es nur gelegentlich macht. > Eigentlich wollte ich vermeiden, persönliches hier auszubreiten. Aber > wenn jemand wie ich Geräte entwickelt, dann hat er mit weitaus mehr als > nur mit Programmierung im allgemeinen und C-Programierung im speziellen > zu tun. Folglich ist jeder Entwicklungsingenieur in deinem Sinne nur > ein Gelegenheitsprogrammierer - oder? Ein Gelegenheitsprogrammierer ist jemand, der nur gelegentlich programmiert. Das ist unabhängig davon, ob er Entwicklungsingenieur ist oder nicht. Ich bin übrigens auch Entwicklungsingenieur und würde mich mit Sicherheit nicht als Gelegenheitsprogrammierer bezeichnen. > Und wenn ich mich hier in diesem Forum umsehe, dann muß ich sehen, daß ganz > viele Leute zwar C benutzen, aber tonnenweise Fehler begehen, die man > eigentlich mit ein wenig logischem Denken nicht gemacht hätte. Bei arg > vielen vermisse ich sogar Grundkenntnisse über die Architektur von > Mikrocontrollern. Das ist in so einem Forum nun nicht ungewöhnlich. Da hängen eben nicht nur Profis rum, die seit 30 Jahren nichts anderes machen. > Und nun kommst du mit der Ansicht, daß man all die tausende von > Wenn-Aber's bei C auswendig kennen soll. Ich wüsste nicht, wo ich sowas behauptet hätte. > Auch Programmiersprachen sollen dem Menschen dienen und nicht umgekehrt. > Hier wurde auch über rein gestalterische Dinge diskutiert wie z.B. > Formatierungen von Quelltexten. Auch dies ist dem Compiler schnurz. Es > dient genauso wie das 'extern' bei Funktionen der menschlichen Lesbarkeit. Und ich sagte bereits, dass es die Lesbarkeit nicht erhöht, sondern - gerade aus gestalterischen Gründen - eher verringert, und zwar schlicht, weil außer dir so gut wie niemand vor Funktionsdeklarationen "extern" davor schreibt. Es wird also für andere erst mal ungewohnt aussehen, und sie werden sich fragen, was das zu bedeuten hat. Mombert H. schrieb: >> Das liegt daran, dass es keine andere Möglichkeit gibt, bei Variablen >> zwischen einer extern-Deklaration und einer Defintion zu unterscheiden. > Auch dafür ist extern nicht wirklich geeignet, da man auch extern vor > die Definition einer Variable schreiben kann ;-) Naja, es ist eben die einzige Möglichkeit. Aber ja, wenn man einen Initializer hat, ist es dann doch eine Definition. Das zeigt aber umso mehr, dass hier nicht das Weglassen von extern bei Funktionen die Ausnahme ist, sondern die Nutzung von extern zur Deklaration bei Variablen.
1 | extern void func1(); // Deklaration mit external linkage |
2 | void func2(); // Deklaration mit external linkage |
3 | |
4 | extern int i1; // Deklaration mit external linkage |
5 | int i2; // Definition mit external linkage |
6 | extern int i3 = 5; // Definition mit external linkage |
Man beachte, dass die Linkage in allen 5 Fällen extern ist, also sowohl bei Variablen, als auch bei Funktionen unabhängig davon, ob man "extern" davor geschrieben hat oder nicht. Bei Variablen ist es also wie schon gesagt nur nötig, um irgendwie sagen zu können, dass es eine reine Deklaration sein soll und keine Definition.
Johannes S. schrieb: > C/C++ sind komplex und... ... und was wolltest du damit eigentlich sagen? So, wie ich deinen Beitrag lese, steht dort: "Leute, macht es so wie alle anderen, die ich kenne. Der Vorteil davon ist, daß ihr es dann so macht, wie alle anderen." Das ist die Tautologie kristallin. Oder andersherum gesagt: "Bloß nicht selber nachdenken, das würde nur die Einigkeit stören." Das klingt in diesen rüden Worten erstmal recht polemisch, steckt aber in der ganzen bisherigen Diskussion drin. Zwar mehr oder weniger unterschwellig, aber das ist nur die Form. Sorry sozusagen. Und nein, C ist nicht komplex, sondern nur kompliziert, weil es eben nicht wirklich logisch aufgebaut ist. Eben deswegen muß man sich viel merken einschließlich der jeweiligen Ausnahmen. Immer nach dem Motto "das ist hier eben so, basta". Ob man das nun liebt oder nicht ist etwas anderes. Aber damit angeben zu wollen, ist albern. W.S.
W.S. schrieb: > Und nein, C ist nicht komplex, sondern nur kompliziert, weil es eben > nicht wirklich logisch aufgebaut ist. Eben deswegen muß man sich viel > merken einschließlich der jeweiligen Ausnahmen. Immer nach dem Motto > "das ist hier eben so, basta". Ob man das nun liebt oder nicht ist etwas > anderes. Aber damit angeben zu wollen, ist albern. Da sind wir uns ja ausnahmsweise mal einig. Oliver
Rolf M. schrieb: > Ausnahme ist, sondern die Nutzung von extern zur Deklaration bei > Variablen. Ich würde sagen, der Ausschluss von extern in tentative definitions ist die Ausnahme. Die Folge ist allerdings die gleiche. Aber ich glaube nicht, dass wir hier über solche Feinheiten diskutieren sollten.
W.S. schrieb: > So, wie ich deinen Beitrag lese, steht dort: > "Leute, macht es so wie alle anderen, die ich kenne. Der Vorteil davon > ist, daß ihr es dann so macht, wie alle anderen." jetzt sind also diejenigen dumm die sich an Standards halten. Sehr steile These. Ich wärme das auf weil ich gerade fremden Quellcode debuggen darf. Die Kollegen haben globale Vars in Headerfiles deklariert und das extern weggelassen. Ich war jetzt so mutig den Code mit der neueren CubeIDE zu übersetzen und die verwendet GCC 10. Der ignoriert diesen Fehler nicht mehr und haut mir eine Latte mehrfach vorhandener Symbole um die Ohren. Da muss man erstmal drauf kommen das sowas ignoriert wurde. https://gcc.gnu.org/gcc-10/porting_to.html So läuft es wenn man Standards mit Füssen tritt und dann noch meint es besser zu wissen.
Johannes S. schrieb: > Der ignoriert diesen Fehler nicht > mehr und haut mir eine Latte mehrfach vorhandener Symbole um die Ohren. Genau das meinte ich, als ich schrieb "mal hat's funktioniert und mal eben nicht". Da kommen dann einige Leute, ganz weit voran ein gewisser Mombert, an und machen einen dumm an, wenn man schreibt, daß man sich genau aus diesem Grund angewöhnt hat , generell das "extern" davor zu schreiben. Wenn Deine Kollegen nicht so faul gewesen wären, hättest Du wahrscheinlich jetzt weniger Stress gehabt.
Zeno schrieb: > Johannes S. schrieb: >> Der ignoriert diesen Fehler nicht >> mehr und haut mir eine Latte mehrfach vorhandener Symbole um die Ohren. > Genau das meinte ich, als ich schrieb "mal hat's funktioniert und mal > eben nicht". Da kommen dann einige Leute, ganz weit voran ein gewisser > Mombert, an und machen einen dumm an, wenn man schreibt, daß man sich > genau aus diesem Grund angewöhnt hat , generell das "extern" davor zu > schreiben. > Wenn Deine Kollegen nicht so faul gewesen wären, hättest Du > wahrscheinlich jetzt weniger Stress gehabt. Ist das so ein Fall wie er bei dir aufgetreten ist? Das ist schon etwas anderes als "mal hat's funktioniert und mal eben nicht". Ein Enwickler (oder mehrere) hat einen Fehler gemacht, und eine neue Compilerversion hat den Fehler aufgedeckt.
Zeno schrieb: > Wenn Deine Kollegen nicht so faul gewesen wären, hättest Du > wahrscheinlich jetzt weniger Stress gehabt. Oder wenn sie einfach nicht auf gut Glück programmiert, sondern die Sprache auch gekannt hätten.
Mombert H. schrieb: > Ist das so ein Fall wie er bei dir aufgetreten ist? Das ist schon etwas > anderes als "mal hat's funktioniert und mal eben nicht". Das ist genau der Fall und nichts anderes als ich beschrieben hatte. Bei dem einen Compiler hat es halt funktioniert beim anderen nicht. Offensichtlich legen die C-Compiler den Standard eben doch unterschiedlich aus. Das möchte man natürlich ungern wahr haben, wenn man in der C-Suppe schwimmt und keine Lust hat mal über den Rand zu schauen. Rolf M. schrieb: > Oder wenn sie einfach nicht auf gut Glück programmiert, sondern die > Sprache auch gekannt hätten. Dto. - offensichtlich muß es ja mal trotz Glücksprogrammierung und ohne Sprachkenntnis mal funktioniert haben. Nein, C hat ein Grundproblem im Sprachdesign und läßt einfach zu viele Ausnahmen, die am Ende keiner mehr überblicken kann zu. Leider nimmt das ganz offensichtlich ein Großteil der C-Programmierer als gottgegeben hin und hat sich im Laufe der Jahre damit arrangiert, was letztendlich dazu geführt hat, das sich die Sprache nur wenig entwickelt hat. Insofern hat der W.S. mit seinen Statements nicht ganz unrecht.
Zeno schrieb: > Mombert H. schrieb: >> Ist das so ein Fall wie er bei dir aufgetreten ist? Das ist schon etwas >> anderes als "mal hat's funktioniert und mal eben nicht". > Das ist genau der Fall und nichts anderes als ich beschrieben hatte. Dann ist ja gut, dann hast du jetzt endlich zugegeben, dass es dein Fehler war, auch wenn du es selbst nicht wahr haben willst. Zeno schrieb: > ein, C hat ein Grundproblem im Sprachdesign und läßt einfach zu viele > Ausnahmen, die am Ende keiner mehr überblicken kann zu. Der C-Standart hat viele Probleme, aber wenn man darüber jammern will, sollte man den Standard wenigstens kennen. Und das tust du offensichtlich nicht.
Zeno schrieb: > Rolf M. schrieb: >> Oder wenn sie einfach nicht auf gut Glück programmiert, sondern die >> Sprache auch gekannt hätten. > Dto. - offensichtlich muß es ja mal trotz Glücksprogrammierung und ohne > Sprachkenntnis mal funktioniert haben. Ja, Compiler werden halt auch weiterentwickelt und erkennen mehr Fehler. Das bedeutet nicht, dass es davor kein Fehler gewesen wäre. Es war nur einer, der halt unerkannt geblieben ist. Genau das meinte ich ja mit "auf gut Glück": Viele gehen offenbar davon aus, dass der Code korrekt wäre, wenn der Compiler ihn nur irgendwie akzeptiert. Wenn ein neuer Compiler ihn dann nicht mehr akzeptiert, beschwert man sich über den oder darüber, dass sich an C irgendwas geändert hätte oder nicht zuverlässig funktionieren würde. Und in Wirklichkeit war da einfach ein Fehler im Programm, der schon immer da war und jetzt eben auffällt. Das Problem ist eben, dass als Reaktion darauf viele nicht auf die Idee kommen, sich mal anzuschauen, wie C eigentlich tatsächlich funktioniert, sondern wieder nur planlos rumbasteln, bis der Compiler es schluckt.
:
Bearbeitet durch User
Mombert H. schrieb: > Dann ist ja gut, dann hast du jetzt endlich zugegeben, dass es dein > Fehler war, auch wenn du es selbst nicht wahr haben willst. Ich habe gar nichts zu gegeben, weil es nichts zuzugeben gibt. Schon erstaunlich was Du aus einem Post herausliest. Aber egal, Du kannst denken was Du willst ist mir auch komplett Rille. Rolf M. schrieb: > Viele gehen offenbar davon aus, dass der Code korrekt > wäre, wenn der Compiler ihn nur irgendwie akzeptiert. Wenn ein Compiler fehlerhaften Code durch winkt, dann ist der Compiler schlichtweg Schrott und das kann man auch nicht schön reden. Ich rate mal, das Schlüsselwort "extern" gibt es in C schon von Anfang an. Dann ist das schon eine Glanzleistung, wenn ein Compiler 10 Hauptrevisionen und unzählige Unterrevisionen braucht um einen Fehler an dieser Stelle zu erkennen. Ein Compiler sollte schon grundlegende Fehler erkennen und dem der vor dem Bildschirm sitzt selbigen mitteilen. GCC scheint an dieser Stelle besonders schlampig zu sein. Mir ist schon öfter aufgefallen das Code welcher vom GCC akzeptiert wird, z.B. vom Keil eher nicht zu 100% akzeptiert wird. Die Borlandcompiler scheinen auch mehr Fehler zu finden. Dummerweise führt halt manchmal kein Weg am GCC vorbei.
Zeno schrieb: > Mombert H. schrieb: >> Dann ist ja gut, dann hast du jetzt endlich zugegeben, dass es dein >> Fehler war, auch wenn du es selbst nicht wahr haben willst. > Ich habe gar nichts zu gegeben, weil es nichts zuzugeben gibt. Schon > erstaunlich was Du aus einem Post herausliest. Vielleicht liege ich falsch und bin alleine damit, aber das ist das was ich in deinem Post lese und ich sehe keine andere Möglichkeit. > Aber egal, Du kannst denken was Du willst ist mir auch komplett Rille. Wenn es dir wirklich egal wäre, würdest du dann antworten? Zeno schrieb: > Ich rate mal, das Schlüsselwort "extern" gibt es in C schon von Anfang an. Hast du mal drüber nachgedacht, warum du raten musst? > Dann ist das schon eine Glanzleistung, wenn ein Compiler 10 Hauptrevisionen > und unzählige Unterrevisionen braucht um einen Fehler an dieser Stelle > zu erkennen. Und hier zeigst du, wie wenig Ahnung du von der Komplexität eines Compilers hast. Warum sollte jemand die Implementierung dieser rein optionale Funktion priorisieren, wenn es echte Probleme zu lösen gibt? Weil du nicht bereit bist die Sprache zu lernen?
Johannes S. schrieb: > Ich wärme das auf weil ich gerade fremden Quellcode debuggen darf. Die > Kollegen haben globale Vars in Headerfiles deklariert und das extern > weggelassen. Ich war jetzt so mutig den Code mit der neueren CubeIDE zu > übersetzen und die verwendet GCC 10. Der ignoriert diesen Fehler nicht > mehr und haut mir eine Latte mehrfach vorhandener Symbole um die Ohren. > Da muss man erstmal drauf kommen das sowas ignoriert wurde. > https://gcc.gnu.org/gcc-10/porting_to.html Danke für den Hinweis. Unser Code mit 30-jähriger Geschichte wird aktuell mit GCC 9.3.0 kompiliert und ich werde gleich mal schauen ob -fno-common gesetzt ist und gegebenenfalls nachschärfen.
Hallo, Zeno schrieb: > Nein, C hat ein Grundproblem im Sprachdesign... Nun ja, "C" ist eben eine pragmatische Sprache und wird heute für für Dinge eingesetzt, für die sie ursprünglich in dieser Form nicht gedacht war. Immerhin ist das "Sprachdesign" ausreichend genug um nach über 50 Jahren immer noch zu den am meisten verwendeten Sprachen überhaupt zu gehören. Zeno schrieb: > ...was letztendlich dazu geführt hat, das sich die Sprache > nur wenig entwickelt hat. Aber das müsstest du doch eigentlich gut finden, denn dadurch bleibt die Sprache übersichtlich und entartet nicht wie andere Sprachen zu Monstern oder werden seit Jahren nicht fertig. Zeno schrieb: > Mir ist schon öfter aufgefallen das Code welcher vom GCC > akzeptiert wird, z.B. vom Keil eher nicht zu 100% > akzeptiert wird. Das könnte aber auch damit zu tun haben das beim GCC im konkreten Fall bestimmte Kompileroptionen nicht ein/ausgeschaltet sind. Hast du denn auch mal probiert ob der GCC über Quellcode für den Kein-Kompiler meckert? rhf
Roland F. schrieb: > Hast du denn auch mal probiert ob der GCC über Quellcode für den > Kein-Kompiler meckert? Nö, habe ich nicht. Es ist mir durch Zufall aufgefallen als ich mal ein Projekt, welches ursprünglich mit dem GCC gemacht wurde mit dem Keil kompiliert habe. Ähnlich ist es auch mit dem CCS (Code Composer Studio) von TI. Da kann man in der IDE zwischen einem TI-Compiler und dem GCC umschalten. Auch dort ist ein deutlich unterschiedliches Verhalten erkennbar. Der GCC ist ist oftmals toleranter.
Mombert H. schrieb: > Vielleicht liege ich falsch und bin alleine damit, aber das ist das was > ich in deinem Post lese und ich sehe keine andere Möglichkeit. Du liegst ganz gewiß falsch. Ich erinnere mich da an eine Diskussion, die ich damals anläßlich der Lernbetty mit jemandem (hab Namen vergessen) geführt hatte wegen Sequenzen in dessen Fernbedienungssoftware. Er hatte mir erklärt, daß das bedingt war durch einige üble Bugs im damaligen GCC. Ich glaub's ihm. Und da ich die Lernbetty mit dem Keil übersetzt hatte, bin ich mit diesem Zoff nicht in Berührung gekommen. Lediglich mit einigen Fanboys gab es Zoff, was die erzeugten Codegrößen betraf. Ich hatte dann doch den GCC in Form der damaligen Yagarto installiert und er hatte funktionablen Code erzeugt, der allerdings deulich umfänglicher war als der vom Keil. Was besagte Fanboys vehement abstritten. Irgendwie erinnerst du mich an die. W.S.
W.S. schrieb: > Mombert H. schrieb: >> Vielleicht liege ich falsch und bin alleine damit, aber das ist das was >> ich in deinem Post lese und ich sehe keine andere Möglichkeit. > > Du liegst ganz gewiß falsch [...] Du hast offensichlich nicht gelesen was ich ursprünglich geschrieben und worauf ich geantwortet habe. W.S. schrieb: > [...] > Ich glaub's ihm. Da liegt das Problem, du glaubst. Du weißt nicht, du hast nicht verstanden und du hast keine Fakten.
Roland F. schrieb: > Aber das müsstest du doch eigentlich gut finden, denn dadurch bleibt die > Sprache übersichtlich und entartet nicht wie andere Sprachen zu Monstern > oder werden seit Jahren nicht fertig. Nun, das kann man so sehen, wenn man will. Oder eben nicht. Es hat durchaus eine Entwicklung bei C gegeben. Siehe vor allem den gravierenden Unterschied zwischen dem originalen C von K&R und dem ANSI-C. Anderes kann man allerdings nur als hilflose Auswüchse bezeichnen, so z.B. 'typedef' oder 'volatile' oder 'static'. Entschuldbar ist das bei 'volatile' und 'static' allerdings durch das Fehlen eines geordneten Unit-Systems in C. Das ist noch immer eines der vielen und eigentlich unentschuldbaren Mankos dieser Programmiersprache. Naja, und die neueste Sau, die durch's Dorf getrieben wurde, sind die lediglich per Textersetzung oder Umbenennung "erzeugten" Datentypen wie 'uint_16' und so weiter. Anstatt endlich einmal die diversen Integer-Typen auf verläßliche Größen festzunageln und bei dieser Gelegenheit den 'char' vom 'int' zu trennen, hat der Standardisierungs-Berg gekreißt und eine schäbige Textersetzung geboren. Und das alles zu einer Zeit, wo gerade bei Textzeichen der Übergang von 8 Bit auf 16 Bit von allen Spatzen der Welt von den Dächern gepfiffen wurde. Nee, C ist nicht entartet, sondern in seinem eigenen Kalk erstarrt. Es ist auch kein Monster geworden, sondern hat mit der Zeit nur unsäglich viele Falten gekriegt. Die sehen aber auch nicht hübsch aus. W.S.
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.