forward declaration einer Funktion hier sinnvoll?

[Chan K. (ckims)]

Hallo,

ich review hier gerade code (author ist leider nicht mehr da)

myApp.c:

void eineFunc(); // forward declaration

void foo(){
  //..
  eineFunc();
  //..
}

andereFile.c

void eineFunc(){
 //macht was
}

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

[c-hater (Gast)]

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.

[Oliver S. (oliverso)]

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

[Bauform B. (bauformb)]

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

[Blechbieger (Gast)]

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. (Firma: matzetronics) (mschoeldgen)]

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

[Oliver S. (oliverso)]

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

[P. S. (namnyef)]

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.

[Rolf M. (rmagnus)]

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.

[A. S. (Gast)]

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

[Stefan F. (Gast)]

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.

[(prx) A. K. (prx)]

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.

[(prx) A. K. (prx)]

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. (Gast)]

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.

[(prx) A. K. (prx)]

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. (Gast)]

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:

void funktionB();

void funktionA() {
  ...
  if (...) funktionB();
}

void funktionB() {
  ...
  if (...) funktionA();
}

[Stefan F. (Gast)]

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

[A. S. (Gast)]

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

[Stefan F. (Gast)]

A. S. schrieb:
> Das ist schon klar. Meine Frage war ...

Ich glaube ich verstehe deine Frage nicht, da sie für mich keinen Sinn 
ergibt.

[W.S. (Gast)]

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.

[W.S. (Gast)]

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.

[Stefan F. (Gast)]

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.

[W.S. (Gast)]

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.

[A. S. (Gast)]

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.

[Stefan F. (Gast)]

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.

[A. S. (Gast)]

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.

[Oliver S. (oliverso)]

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

[Wilhelm M. (wimalopaan)]

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

Jede Definition ist eine Deklaration.

[Stefan F. (Gast)]

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.

[Oliver S. (oliverso)]

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

[W.S. (Gast)]

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.

[Wilhelm M. (wimalopaan)]

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

Nicht notwendigerweise: es ist "implementation-defined"

[Wilhelm M. (wimalopaan)]

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

[Oliver S. (oliverso)]

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. (Gast)]

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.

[Wilhelm M. (wimalopaan)]

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"

[Wilhelm M. (wimalopaan)]

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

static void foo();

//...

static void foo() {
//...
}

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

[A. S. (Gast)]

A. S. schrieb:
> Aber WENN so passende .h gefunden wird, DANN wird nochmal so gesucht,
> als hätte <> da gestanden.

Aber WENN so keine passende .h ...

[Wilhelm M. (wimalopaan)]

besser

[A. S. (Gast)]

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)

[Nosnibor (Gast)]

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.

[Wilhelm M. (wimalopaan)]

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.

[Rolf M. (rmagnus)]

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.

[Wilhelm M. (wimalopaan)]

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

[Rolf M. (rmagnus)]

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.

[Wilhelm M. (wimalopaan)]

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 (Gast)]

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

[Wilhelm M. (wimalopaan)]

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. (prx)]

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

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

[Wilhelm M. (wimalopaan)]

(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?

[(prx) A. K. (prx)]

Ich

[Rolf M. (rmagnus)]

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 (Gast)]

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

[Wilhelm M. (wimalopaan)]

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?

[(prx) A. K. (prx)]

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.

[Wilhelm M. (wimalopaan)]

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