Forum: PC-Programmierung C -> Missverständnis über h-files und Inkludierung (?)


von Jasson J. (jasson)


Angehängte Dateien:

Lesenswert?

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.

von Tim T. (tim_taylor) Benutzerseite


Lesenswert?

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
von Kosackenzipfel (Gast)


Lesenswert?

Liegt meist am falschen aufruf von gcc/g++, der Linker findet dann nix.
Alle relevanten files mit angeben dann geht es.

von Tim T. (tim_taylor) Benutzerseite


Lesenswert?

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.

von Jasson J. (jasson)


Angehängte Dateien:

Lesenswert?

:) 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 :)

von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Tim T. (tim_taylor) Benutzerseite


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von Jasson J. (jasson)


Lesenswert?

^^zum Glück ist mein Problem schon gelöst - jetzt kann ich Popcorn 
machen und dem Thread beim entgleisen zu schauen :)

von Dirk B. (dirkb2)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Rolf M. (rmagnus)


Lesenswert?

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.

von A. S. (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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
von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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 ;-)

von A. S. (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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?

von A. S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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
von Mombert H. (mh_mh)


Lesenswert?

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.

von Klaus W. (mfgkw)


Lesenswert?

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".

von Mombert H. (mh_mh)


Lesenswert?

Klaus W. schrieb:
> "extern" heißt also eher "möglicherweise extern".
Nein! extern heißt "jeder kann mich von extern sehen".

von Klaus W. (mfgkw)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Dirk B. (dirkb2)


Lesenswert?

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.

von Dirk B. (dirkb2)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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
von Nachdenklicher (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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 ;-)

von Dirk B. (dirkb2)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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
von Nachdenklicher (Gast)


Lesenswert?

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

von W.S. (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

W.S. schrieb:
> ich
> arbeite OHNE Linkerscripte und MIT dem Keil bei Arm

Über diese Aussage müsstest du dann doch nochmal nachdenken.

Oliver

von Johannes S. (Gast)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Mombert H. (mh_mh)


Lesenswert?

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.

von Johannes S. (Gast)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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.

von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von Rolf M. (rmagnus)


Lesenswert?

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
von Zeno (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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?

von Blechbieger (Gast)


Lesenswert?

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.

von Roland F. (rhf)


Lesenswert?

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

von Zeno (Gast)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Mombert H. (mh_mh)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.