[C] Programm um Header und Source Dateien abzugleichen

Sowas nennt sich nach meinem Kenntnisstand Compiler. Den auf die Dateien 
loslassen, und du bekommst detaillierte Informationen über jede einzelne 
Problemstelle ;)

Oliver

Ja, das ist der Ist-Zustand ;)

Ich brödel oft Bibliotheken zusammen bei denen ich nicht sofort alles 
benutze- da fällt so ein Fehler zwischen Deklaration und Definition dann 
auch erst später auf und beherbergt ein Überraschungsmoment ;)

Mit GCC empfiehlt sich neben anderen Warnungen immer 
-Wmissing-prototypes und -Wstrict-prototypes.

Ich benutze -Wall, sollte also drin sein.

QtCreator bietet bei der Änderung einer Parameterklammer einer Funktion 
in der .c-Datei an, dies in der Headerdatei gleich mit zu erledigen (da 
erscheint im Editor eine Glühbirne, die man nur anzuklicken hat).

Heiko L. schrieb:
> Ich brödel oft Bibliotheken zusammen bei denen ich nicht sofort alles
> benutze- da fällt so ein Fehler zwischen Deklaration und Definition dann
> auch erst später auf und beherbergt ein Überraschungsmoment ;)

Verstehe ich nicht.

Wenn Du die h-Datei mit den Deklarationen auch in der C-Datei 
includierst, welche die Funktionen oder Variablen definiert, dann 
findet der Compiler auch die Missstände, die normalerweise vielleicht 
nicht auffallen, weil Du die Funktion X gar nicht aufrufst.

Es hängt also nicht davon ab, ob Du eine Funktion nutzt oder nicht.

Frank M. schrieb:
> Wenn Du die h-Datei mit den Deklarationen auch in der C-Datei
> includierst, welche die Funktionen oder Variablen definiert,

Ehrlich gesagt mache ich das nur wenn es nicht anders geht, aber schaden 
kann es ja eigentlich nicht.

Aber der compiler (hier avr-gcc) meckert z.B. nicht über nicht 
definierte Deklarationen. Auch sehe ich keine Fehlermeldungen zu nicht 
deklarierten Definitionen (das wäre ja auch ziemlich unlogisch).

Man würde dann aber schon merken wenn Datentypen oder Parameter nicht 
passen.

Danke!

Der Makefile-Generator sieht auch interessant aus ;)

Heiko L. schrieb:
> Ehrlich gesagt mache ich das nur wenn es nicht anders geht,

Das muss immer gehen. Und man sollte es auch immer machen - und zwar 
als erstest. Wenn das (aus welchen Gründen auch immer) nicht geht, dann 
hast Du einen Designfehler im Programm.

> aber schaden kann es ja eigentlich nicht

Ganz im Gegenteil. Es zeigt sofort die Fehler bzgl. des Interfaces, noch 
bevor Du die Funktionen überhaupt nutzt.

Peter II schrieb:
> Wenn sie nur ein einer C Datei gebraucht werden muss man sie
> nicht ins headfile schreiben.

Eben. Und man sollte sie dann auch static definieren. Erstens kann der 
Compiler dann besser optmieren, zweitens läuft man auch nicht Gefahr, 
sie "versehentlich" später trotzdem aus einem externen Modul aufzurufen.

Heiko L. schrieb:
> Ja, das ist der Ist-Zustand ;)
>
> Ich brödel oft Bibliotheken zusammen bei denen ich nicht sofort alles
> benutze- da fällt so ein Fehler zwischen Deklaration und Definition dann
> auch erst später auf und beherbergt ein Überraschungsmoment ;)

Hä?
WIe das?

WEnn jedes C-File aus deiner Bibliothek sein eigenes Header File 
inkludiert, dann fällt eine eventuelle Abweichung SOFORT auf, weil die 
Bibliothek dann schon gar nicht mehr durchcompiliert!

Daher: Jedes C-File inkludiert IMMER auch das Header File, in dem die 
Protoypen der von diesem C-File exportierten Funktionen drinn sind.
Das nicht zu tun, wäre allerdings wirklich grob fahrlässig.

Wieder etwas gelernt :D

Danke!

Genauso wie so etwas

bar.c:

1

#include <stdio.h>

2

#include "xyz.h"

3

4

extern foo( int a );   // sollte eigentlich in xyz.h drinnen sein

5

6

void bar()

7

{

8

  foo( 5 );

9

}

Wenn du so eine unmotivierte extern Funktionsdeklaration in einem Source 
Code File siehst, dann druckst du das C-File aus, und drischt es dem 
Autor solange um die Ohren, bis nur noch Konfetti vorhanden ist.
Syntaktisch ist das legal. Aber nicht alles was syntaktisch legal ist, 
ist auch programmiertechnisch sinnvoll.
Beides zusammen, nicht inkludieren und unmotivierte 'extern' 
Deklarationen sind ungefähr vergleichbar damit, dass du Sebastian Vettel 
vorschlägst den nächsten Grand Prix ohne Sicherheitsgurt zu fahren. Man 
kann es probieren, aber er wird dir einen Vogel zeigen.

Heiko L. schrieb:
> Ich benutze -Wall, sollte also drin sein.

"sollte" sollte vielleicht so sein, ist es aber nicht. Der Begriff "all" 
in -Wall ist nicht wörtlich zu nehmen. Zum einen wäre ja sonst -Wextra 
überflüssig, zum anderen wären die vom Johann gennannten Warnungen nicht 
mal damit aktiviert.

Da hilft nix ausser RTFM.

Oliver

Ok, jetzt habe ich in TFM mal geschaut und die Optionen zugeschaltet.

Nochmal was gelernt :)

Danke.

Heiko L. schrieb:
> Ich benutze -Wall, sollte also drin sein.

Nein. -Wall sind nicht alle Warnungen!

Johann L. schrieb:
> Heiko L. schrieb:
>> Ich benutze -Wall, sollte also drin sein.
>
> Nein. -Wall sind nicht alle Warnungen!

Dann sollte man hierfür vielleicht mal einen vernünftigen Namen 
vergeben. ;-)

z.B. -Wusual oder -Wstandard

Mark B. schrieb:
> Johann L. schrieb:
>> Heiko L. schrieb:
>>> Ich benutze -Wall, sollte also drin sein.
>>
>> Nein. -Wall sind nicht alle Warnungen!
>
> Dann sollte man hierfür vielleicht mal einen vernünftigen Namen
> vergeben. ;-)
>
> z.B. -Wusual oder -Wstandard

Zu allererst kann man mal die Doku lesen und verstehen, was man da 
aktiviert oder nicht:

1

Note that some warning flags are not implied by -Wall.

2

Some of them warn about constructions that users generally do not

3

consider questionable, but which occasionally you might wish to

4

check for; others warn about constructions that are necessary or

5

hard to avoid in some cases, and there is no simple way to modify

6

the code to suppress the warning. Some of them are enabled by

7

-Wextra but many of them must be enabled individually.

Johann L. schrieb:
> Zu allererst kann man mal die Doku lesen und verstehen, was man da
> aktiviert oder nicht:

Das ändert nichts daran, dass die Bezeichung "all" ungeschickt gewählt 
ist. Man darf Dinge ruhig sinnvoll benennen.

Mark B. schrieb:
> Johann L. schrieb:
>> Zu allererst kann man mal die Doku lesen und verstehen, was man da
>> aktiviert oder nicht:
>
> Das ändert nichts daran, dass die Bezeichung "all" ungeschickt gewählt
> ist. Man darf Dinge ruhig sinnvoll benennen.

Na es zwingt ja niemand, Sammeloptionen wie -W, -Wall, -Os, -O2, 
-Wextra, -ffast-math etc. zu verwenden.

Die GCC-Entwickler sind bestrebt, solche Optionen halbwegs kompatibel zu 
halten und nicht von Version zu Version mit geänderten Suboptionen à la 
surprise aufzuwarten.

Außerdem war -Wall noch nie die Sammlung aller Warnungen.  Guckst du 
z.B. GCC 2.95 (Release 1999) 
https://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_2.html#SEC8