forward declaration einer Funktion hier sinnvoll?

Ohne forward-Deklaration geht es nicht. Die Frage, warum die im .c-File 
steht, und nicht in andereFile.h, was dann inkludiert werden würde, kann 
hier niemand beantworten.

Letzteres wäre im Normalfall der saubere Weg. Ob da aber der Normalfall 
anwendbar ist, kannst nur du wissen.

Und die Antwort auf die Frage, ob du unter "review" das gleiche 
verstehst, wie der Rest der Welt, ist ebenfalls offen.

Oliver

Der Vorteil dieser forward declaration ist, dass die unabhängig von der 
eigentlichen Funktion frei wählbar ist. Das braucht man, wenn man z.B. 
an eineFunc(int foo) ein double übergeben möchte. Damit sind Tricks 
möglich, die auch mit einer union nicht möglich sind ;)

Oder man erklärt in einer *.c die betreffende Funktion als 'extern'.

Matthias S. schrieb:
> Oder man erklärt in einer *.c die betreffende Funktion als
> 'extern'.

Wieso wäre das dann anders als das, was der TO vorgefunden hat?

Oliver

Könnte Murks sein.

In der Regel hat man entweder eine lokale Funktion. Dann sind Prototyp, 
Implementierung und die Aufrufe alle in einem Modul. Oder die Funktion 
wird eben von einem anderen Modul verwendet. Dann macht man die Funktion 
mit dem Header File des Moduls, das die Funktion implementiert, dem 
anderen Modul bekannt.

Chan K. schrieb:
> ersuche gerade zu ergründen, ob das irgendwelche vorteile haben kann,
> mit forward decls zu arbeiten, anstatt ganz normal eineFunc() in einer
> andereFile.h zu veröffentlichen und dann zu inkludieren in myApp.c...

Beides sind Forward-Deklarationen. Sie stehen nur an unterschiedlicher 
Stelle. Es ergibt eigentlich nur dann Sinn, die nicht in den Header zu 
stecken, wenn sie nur von diesem einen File aus aufgerufen werden soll.

Oliver S. schrieb:
> Ohne forward-Deklaration geht es nicht.

Doch, in C geht es auch ohne. Sollte man aber natürlich vermeiden und am 
besten per Compiler-Option verbieten.

Chan K. schrieb:
> void eineFunc();

Von diesem K&R-Stil würde ich bei C abraten, denn das steht für eine 
Funktion mit unbekannten Parametertypen.

Stefan ⛄ F. schrieb:
> Innerhalb einer *.c Datei brauche ich forward Deklarationen nur, wenn
> zwei Funktionen sich gegenseitig aufrufen also zirkulär abhängig sind.

Wer die Hauptfunktion oben schreibt und die davon aufgerufenen 
Funktionen dahinter, kommt nicht ohne sie aus. Man kann das auch 
umgekehrt machen, aber das ist eben eine Stilfrage.

A. S. schrieb:
> Wie ist das gemeint? Dass Du nur dann auch forward deklarieren würdest,
> wenn Du es in C nicht brauchst?

Auf Funktionen bezogen, die nur innerhalb eines Quellfiles definiert und 
genutzt werden, sind reine Deklarationen ohne Implementierung meist 
unnötig. Vorausgesetzt, man platziert die Implementierung vor den 
Aufruf. In solchen Quelltexten sind die Top-Level Funktionen ganz unten 
und die Bottom-Level Funktionen ganz oben.

Manchen widerstrebt dieser Stil. Die schreiben dann eben oben eine Liste 
an forwards, danach den Top-Level, und die übrigen darunter.

Stefan ⛄ F. schrieb:
> A. S. schrieb:
>>> Innerhalb einer *.c Datei brauche ich forward Deklarationen nur, wenn
>>> zwei Funktionen sich gegenseitig aufrufen also zirkulär abhängig sind.
>
>> Wie ist das gemeint?
>
> So:
> 1void funktionB();
> 23void funktionA() {
> 4  ...
> 5  if (...) funktionB();
> 6}
> 78void funktionB() {
> 9  ...
> 10  if (...) funktionA();
> 11}

Die zirkuläre Abhängigkeit hat damit nichts zu tun. Jede Funktion muß 
vor einem Aufruf deklariert sein (in C: sollte). Damit braucht es die 
Deklaration von B() vor ihrem Aufruf in A(), aber es braucht keine für 
A() für den Aufruf von A() in B().

Oliver

Oliver S. schrieb:
> aber es braucht keine für
> A() für den Aufruf von A() in B().

Jede Definition ist eine Deklaration.

Wilhelm M. schrieb:
> Oliver S. schrieb:
>> aber es braucht keine für
>> A() für den Aufruf von A() in B().
>
> Jede Definition ist eine Deklaration.

Eben.

Oliver

A. S. schrieb:
> "" sucht zuerst im Ordner der C-Datei und danach (wie <>) in
> include-Pfaden.

Nicht notwendigerweise: es ist "implementation-defined"

A. S. schrieb:
> kann Du dort eine .h für dessen interne
> Definitionen/Deklarationen liegen.

Besser keine Definitionen in Header-Dateien (ggf. Verletzung der ODR).

Stefan ⛄ F. schrieb:
> Oliver S. schrieb:
>> Die zirkuläre Abhängigkeit hat damit nichts zu tun.
>
> Doch schon, denn ohne zirkuläre Anhängigkeit habe ich die Möglichkeit,
> sie in die richtige Reihenfolge zu bringen.

Die Diskussion, ob die Anordnungen von Funktionen in einer Sourcedatei 
nach der minimalen Anzahl von forward-Deklarationen „richtig“ ist, 
könnten wir hier jetzt führen, aber das ist so sinnvoll wie alle 
Diskussionen über solche Stilfragen.

Ich sag mal, da gibt es wesentlich sinnvollere Ordnungskriterien.

Oliver

A. S. schrieb:
> Wilhelm M. schrieb:
>> A. S. schrieb:
>>> "" sucht zuerst im Ordner der C-Datei und danach (wie <>) in
>>> include-Pfaden.
>>
>> Nicht notwendigerweise:
>
> Teilweise richtig: Ob und was bei "" zuerst passiert, ist implementation
> defined.
> Aber WENN so passende .h gefunden wird, DANN wird nochmal so gesucht,
> als hätte <> da gestanden.

Da fehlt ein "nicht"

Letztendlich geht es bei der Frage des TO darum, wie man in C die 
private und die öffentliche Schnittstelle eines Modules trennt. Dies 
geht nur über Übersetzungseinheit-lokale (internal linkage) 
Deklarationen für das private Modul-Interface:

in `foo.c`:

1

static void foo();

2

3

//...

4

5

static void foo() {

6

//...

7

}

Alles was external linkage hat, ist extern erreichbar. Dies hat auch 
erst zweitrangig mit der Bereitstellung einer Header-Datei zu tun. Das 
ist dann "nur" convenience. Einmal extern, immer extern (das 
Schlüsselwort darf, muss aber bei Funktionen nicht stehen).

besser

Nosnibor schrieb:
> Ich sehe da keinen großen Vorteil, aber einen richtig üblen Nachteil:
> Wenn sich die Deklaration von eineFunc() je ändert (z.B. ein weiterer
> Parameter dazukommt), stößt einen normalerweise der Compiler mit der
> Nase darauf, falls man das bei irgendeinem Aufruf noch nicht
> berücksichtigt hat. Wenn die Funktion aber in irgendeinem myApp.c
> nochmal unabhängig deklariert wurde, kann der Compiler den Widerspruch
> zur Definition in andereFile.c nicht sehen, und dann knallt es eben zur
> Laufzeit, wo die Fehlersuche sehr aufwendig werden kann.

Das ist falsch, oder Du meinst was ganz anderes.

Egal wie eine Deklaration in den Code kommt, durch manuelles Einfügen in 
den Code oder durch eine Einfügen durch den CPP (der Cpp ist ein 
nicht-interaktiver Editor), der Compiler deckt Differenzen zwischen 
Deklaration und Definition auf.

Wilhelm M. schrieb:
> Egal wie eine Deklaration in den Code kommt, durch manuelles Einfügen in
> den Code oder durch eine Einfügen durch den CPP (der Cpp ist ein
> nicht-interaktiver Editor), der Compiler deckt Differenzen zwischen
> Deklaration und Definition auf.

Um das zu können, muss er aber auch beide sehen.

Wilhelm M. schrieb:
> Das ist falsch, oder Du meinst was ganz anderes.

Er meint, dass der Compiler im einen Fall die forward-Deklaration und 
die Definition beide sehen kann, im anderen Fall nicht und daher auch 
nicht prüfen kann, ob sie von einander abweichen.

Rolf M. schrieb:
> Er meint, dass der Compiler im einen Fall die forward-Deklaration und
> die Definition beide sehen kann, im anderen Fall nicht und daher auch
> nicht prüfen kann, ob sie von einander abweichen.

Wenn es der Compiler nicht prüfen kann, dann merkt es der Linker und 
quittiert es mit "undefined reference".

Wilhelm M. schrieb:
> Wenn es der Compiler nicht prüfen kann, dann merkt es der Linker und
> quittiert es mit "undefined reference".

In der Regel nicht, da es nicht das Name-Mangling wie in C++ gibt (meist 
entweder gar keins oder ein sehr einfaches) und somit der Linker die 
Parameter-Typen der Funktion nicht kennt.

Rolf M. schrieb:
> Kommt drauf an. In den meisten Fällen nicht, da es nicht das
> Name-Mangling wie in C++ gibt (meist entweder gar keins oder ein sehr
> einfaches) und somit der Linker die Parameter-Typen der Funktion nicht
> kennt.

Oh ha, merke ich jetzt erst, dass der TO von C spricht ... sorry for the 
noise (das bestätigt mal wieder mein Vorurteil, dass man C-Code nur 
sinnvoll als C++-Code übersetzen kann).

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Oh ha, merke ich jetzt erst, dass der TO von C spricht ... sorry for the
>> noise (das bestätigt mal wieder mein Vorurteil, dass man C-Code nur
>> sinnvoll als C++-Code übersetzen kann).
>
> Das glauben natürlich nur C++-ler...

Na klar ;-)

> Diese Typen sind sich schlicht nicht darüber im klaren, welche Unmassen
> an Erbsünden C++ aus C "importiert".

Genau: C ist der Quell des Übels.

> Also: Es ist kein großes Problem, C++-Code genauso unsicher zu machen
> wie C-Code. Und jeder, der das bestreitet, gehört geteert und gefedert.

Wenn wir bei diesem hier geschilderten Fall bleiben, ist allerdings 
schon besser.

> Also: wenn OO-Hochsprache und hohe Codesicherheit das Ziel ist, dann ist
> C++ das ALLERLETZTE was man wählen sollte.

Wer hat hier von OO gesprochen? C++ ist keine OO-Sprache, sondern eine 
multi-paradigmen Sprache.

Wilhelm M. schrieb:
> Wer hat hier von OO gesprochen? C++ ist keine OO-Sprache!

Apropos: Hat schon jemand Smalltalk auf einen ATtiny probiert? ;-)

(prx) A. K. schrieb:
> Wilhelm M. schrieb:
>> Wer hat hier von OO gesprochen? C++ ist keine OO-Sprache!
>
> Apropos: Hat schon jemand Smalltalk auf einen ATtiny probiert? ;-)

Wer hat denn was von AVRs gesagt?

Ich

c-hater schrieb:
> Wilhelm M. schrieb:
>
>> Oh ha, merke ich jetzt erst, dass der TO von C spricht ... sorry for the
>> noise (das bestätigt mal wieder mein Vorurteil, dass man C-Code nur
>> sinnvoll als C++-Code übersetzen kann).
>
> Das glauben natürlich nur C++-ler...

Wer richtig C++ kann, weiß es. Wer es nicht so gut kann, glaubt es. Und 
wer es gar nicht kann, glaubt es nicht.

> Also: Es ist kein großes Problem, C++-Code genauso unsicher zu machen
> wie C-Code. Und jeder, der das bestreitet, gehört geteert und gefedert.

Klar, wer nicht damit umgehen kann, bringt da genauso schlechten Code 
zustande. Allerdings gibt's halt deutlich mehr Möglichkeiten, den Code 
sicher zu machen. Man muss sie allerdings auch nutzen. Das ist so 
ähnlich wie beim Sicherheitsgurt. Der ist auch nur dann sicher, wenn man 
ihn anlegt.

Wilhelm M. schrieb:
> Wer hat hier von OO gesprochen? C++ ist keine OO-Sprache, sondern eine
> multi-paradigmen Sprache.

Ja, unter anderem auch OO.

c-hater schrieb:
> Mit dieser Erbsünde hatte C++ von Anfang an die Option verspielt, eine
> "konzeptionell sichere" Sprache zu sein/werden.

Und ohne diese "Erbsünde" hätte C++ nie den hohen Verbreitungsgrad 
erreicht. Welcher Tod ist der süßere?

c-hater schrieb:
> Der Quell des Übels ist, dass C++ diesen "Import" nicht vollkommen
> unmöglich gemacht hat. Die Entscheidung fiel hier pro Kompatibilität und
> kontra Sicherheit.

Korrekt. C++ trägt diese Absicht allerdings schon im Namen. Es gibt 
beliebig viele Programmiersprachen, die nichts mit C zu tun haben. Bei 
Mikrocontrollern sind es indes nicht ganz so viele.

A. S. schrieb:
> Wilhelm M. schrieb:
>> Letztendlich geht es bei der Frage des TO darum, wie man in C die
>> private und die öffentliche Schnittstelle eines Modules trennt.
>
> Genaugenommen wissen wir das nicht. Und der TO vermutlich auch nicht, da
> er das Konstrukt nur gefunden hat.
>
> Es wäre aber möglich, dass TO und Autor nur den Unterschied zwischen ""
> und <> nicht kennen und quasi nur mit "public" headern arbeiten und die
> API nicht mit internas zuschütten möchten.
>
> (ist aber nur Spekulation, da der TO nichts dazu gesagt hat)

Ja, vermutlich hat sich der TO wieder entsetzt von diesem Forum 
abgewendet ;-)