Hallo,
ich review hier gerade code (author ist leider nicht mehr da)
myApp.c:
1
voideineFunc();// forward declaration
2
3
voidfoo(){
4
//..
5
eineFunc();
6
//..
7
}
andereFile.c
1
voideineFunc(){
2
//macht was
3
}
versuche 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...
Chan K. schrieb:> versuche gerade zu ergründen, ob das irgendwelche vorteile haben kann
Kein wirklichen (eher das Gegenteil), jedenfalls nicht, wenn die
Realität so aussieht, wie du sie gezeigt hast.
Aber sehr wahrscheinlich sieht sie anders aus und du hast nur den
eigentlichen Trick nicht verstanden, und deshalb das wirklich Wichtige
nicht mitgepostet.
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 ;)
Gibt es ein andereFile.h? Falls ja wäre das ein (unschöner) Trick um
eineFunc() nur für myApp.c und nicht für alle die den Header inkludieren
bekannt zu machen. Sauberer wären zwei getrennte Header.
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.
Meist gibt es keine passende include Datei. Die eine Funktion ist aus
einem anderen ecosystem wo irgendein ein Typ int statt Long ist oder
eine eigene Definition für true hat und das würde knallen.
Oder es ist quick and dirty
Innerhalb einer *.c Datei brauche ich forward Deklarationen nur, wenn
zwei Funktionen sich gegenseitig aufrufen also zirkulär abhängig sind.
Solche Konstrukte vermeide ich allerdings generell.
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.
Stefan ⛄ F. 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? Dass Du nur dann auch forward deklarieren würdest,
wenn Du es in C nicht brauchst? Oder dass Du Forward-Deklarationen
löschst, wenn Du sie obsolete werden? Oder es einen Unterschied macht,
ob Du nur einen Funktions-Pointer davon nutzt? Oder dass es keine rolle
spielt, ob sie static oder global ist?
Ich mach es anders rum: Alle haben eine forward-Deklaration, egal ob in
Header ODER auch mal als extern davor. Nur für static verzichte ich
ausnahmsweise, wenn sie klar erkennbar reine Hilfsfunktion nachfolgender
Funktionen ist.
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.
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:
(prx) A. K. schrieb:> In solchen Quelltexten sind die Top-Level Funktionen ganz unten> und die Bottom-Level Funktionen ganz oben.>> Manchen widerstrebt dieser Stil.
Mir ist die Reihenfolge ziemlich egal, solange es funktioniert. Ich bin
den Umgang mit großen Quelltexten gewohnt, so man sowie mit Hilfe einer
IDE navigiert.
Das Einzige was (in allen Firmen wo ich bisher war) stets gleich
gehalten wurde war, dass globale Variablen nach ganz oben kommen.
Für mich beschreiben Header Dateien das API, also Teile die man von
außen benutzen soll. Dort hin gehören keine Forward Deklarationen für
interne Funktionen. Jedoch würde ich es einfach so stehen lassen, wenn
ich mal drauf Stoße. Man kann die Gurke auch mal krumm sein lassen.
Stefan ⛄ F. schrieb:> So:
Das ist schon klar. Meine Frage war, warum Du das auf wechselseitig
aufrufende Funktionen beschränkst oder ob Du die Deklaration ggf. wieder
wegnimmst.
Du hast aber weiter unten dann erklärt, dass einfach deklarierst, bis es
funktioniert und Du keinem generellen Style folgst. Das ist auch völlig
OK.
Stefan ⛄ F. schrieb:> Mir ist die Reihenfolge ziemlich egal, solange es funktioniert.
Mit #include-Dateien machen das viele auch so. Sie haben keinen
generelles Konzept (z.B. sys.h die dann alle System-Header einbindet)
sondern binden nur das ein, was der Compiler gerade anmeckert. Damit
schließt sich der Kreis zum Ausgangspost ;-)
A. S. schrieb:> sondern binden nur das ein, was der Compiler gerade anmeckert.
Genau DAS ist auch der beste Weg. Man sollte eine gerade zu übersetzende
Quelle nicht mit der Gießkanne zuschütten, sondern nur mit den
Referenzen zu anderen Quellen, auf die er sich tatsächlich bezieht. Das
erleichtert die Übersicht über die Relationen zwischen verschiedenen
Quellen gar sehr.
Natürlich ist es auch nicht verboten, mit der Gießkanne zu arbeiten,
oder Einzelreferenzen direkt in eine Quelle einzuarbeiten. Aber man
erschwert sich damit die Übersicht.
W.S.
Stefan ⛄ F. schrieb:> Für mich beschreiben Header Dateien das API, also Teile die man von> außen benutzen soll. Dort hin gehören keine Forward Deklarationen für> interne Funktionen.
Im Grunde hast du ja Recht, aber all das, was in einer Header-Datei
steht, ist letztlich eine Forward-Deklaration für interne Funktionen der
zugehörigen Quelldatei. Das wird rein textuell in die benutzende Quelle
eingefügt. All das ist letztlich nur C-typisch, weil in C ein
ordentliches Modulsystem fehlt.
W.S.
W.S. schrieb:> Im Grunde hast du ja Recht, aber all das, was in einer Header-Datei> steht, ist letztlich eine Forward-Deklaration
Klar, dem will ich nicht widersprechen.
Chan K. schrieb:> ich review hier gerade code (author ist leider nicht mehr da)
Also du schaust dir Programmquellen an, die jemand anderes geschrieben
hat.
Nun, Deklarationen für Funktionen, die in anderen Quellen existieren,
sollte man besser in die zugehörigen Headerdateien dieser anderen
Quellen setzen, damit man besser den Überblick behält.
Und inerhalb einer Quelle sollte man lieber auf eine sinnvolle Anordnung
der verschiedenen Funktionen im Quelltext achten, damit man möglichst
nur die notwendigen Forward-Deklarationen machen muß.
W.S.
Stefan ⛄ F. schrieb:> Ich glaube ich verstehe deine Frage nicht, da sie für mich keinen Sinn> ergibt.
Ja, ist mir jetzt auch klar. Ein oft rezipiertes Forenmitglied lässt
z.B. unnötige Klammern weg. Das ist seine Maxime. Vermutlich entfernt er
Klammern, die obsolete geworden sind. Bei Dir scheint die Beschränkung
auf Kreuzaufrufe daher zu resultieren, dass Du andere Konflikte bisher
nicht hattest.
Stefan ⛄ F. schrieb:> Für mich beschreiben Header Dateien das API, also Teile die man von> außen benutzen soll. Dort hin gehören keine Forward Deklarationen für> interne Funktionen.
Da unterscheidet man ja in der Regel zwischen öffentlichen API-Headern
und internen Headern, in C auch durch <x.h> und "y.h".
Und davon nochmals reine Datengräber. Also include-Dateien, die nur
einmal in eine einzige .c eingebunden werden und z.B. einen Font oder
Grafiken enthalten. Eine .h nur mit Deklarationen und #defines für nur
eine .c-Datei ist natürlich unnötig.
A. S. schrieb:> Da unterscheidet man ja in der Regel zwischen öffentlichen API-Headern> und internen Headern, in C auch durch <x.h> und "y.h".
Nach meinem Verständnis dient dies der Unterscheidung zwischen zentral
installierten Bilbiotheken (wie die von der Toolchain), versus
Bibliotheken im Projekt.
Stefan ⛄ F. schrieb:> Nach meinem Verständnis dient dies der Unterscheidung zwischen zentral> installierten Bilbiotheken (wie die von der Toolchain), versus> Bibliotheken im Projekt.
"" sucht zuerst im Ordner der C-Datei und danach (wie <>) in
include-Pfaden.
Wenn ein Modul XYZ aus zwei oder mehr C-Dateien besteht (ggf. im
Unterordner XYZ), kann Du dort eine .h für dessen interne
Definitionen/Deklarationen liegen. Die ist dann von anderen Quellen
nicht erreichbar (bzw. nur per relativen/absoluten Pfaden) und sozusagen
"lokal".
Bei uns spricht man von local- und public-Headern, keine Ahnung ob es
dafür einen Terminus gibt.
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:> 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.
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
Stefan ⛄ F. schrieb:> Nach meinem Verständnis dient dies der Unterscheidung zwischen zentral> installierten Bilbiotheken (wie die von der Toolchain), versus> Bibliotheken im Projekt.
Genau so ist es. Es ist nur der Unterschied zwischen einem eigenen Pfad
zur Datei und dem Standardpfad zur Datei. Eine reine
Pfad-Findungs-Angelegenheit.
W.S.
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
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.
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
staticvoidfoo();
2
3
//...
4
5
staticvoidfoo(){
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).
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)
Chan K. schrieb:> versuche 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...
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.
Meist macht man solche Schmuddeleien, wenn es schnell gehen muss, die
include-Ketten unübersichtlich sind, und man zu faul ist, "extra für
diese Funktion" ein neues .h aufzumachen. Das sollte aber nicht so
stehen bleiben.
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).
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...
Diese Typen sind sich schlicht nicht darüber im klaren, welche Unmassen
an Erbsünden C++ aus C "importiert".
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.
Also: wenn OO-Hochsprache und hohe Codesicherheit das Ziel ist, dann ist
C++ das ALLERLETZTE was man wählen sollte.
Zehntausende von bekannten Sicherheitslücken können nicht lügen...
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.
(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?
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.
Wilhelm M. schrieb:> Genau: C ist der Quell des Übels.
Nein. 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.
Mit dieser Erbsünde hatte C++ von Anfang an die Option verspielt, eine
"konzeptionell sichere" Sprache zu sein/werden.
Dass C dies nicht ist, steht ja ohnehin fest. Das stand aber auch schon
fest, als C++ designed wurde...
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 ;-)