1.) static außerhalb von class:
Was für einen Sinn hat bzw. wie funktioniert eine static-deklarierte Funktion außerhalb einer Klasse? Bsp.:

static void Func1(void)
{
}

int main()
{
  return 0;
}

Deklariere ich static-Funktionen oder static-Variablen innerhalb von Klassen erwirkt man ja damit, dass diese statischen Elemente (Variablen, Konstanten oder Funktionen) pro Klasse nur einmal existieren und nicht, wie ihre Member-Pendants, einmal pro Instanz.
Da ist ja die Zugehörigkeit klar, also zur Klasse.
Wenn ich aber nun wie im Beispiel einfach nur eine static-Funktion außerhalb der main()-Funktion, also im globalen Namespace oder meinetwegen auch in irgendeinen Namespace deklariere, zu was ist diese dann zugehörig und hätte das überhaupt einen Nutzen, einen Anwendungsfall? Übersetzen lässt es sich ja, ich frage mich gerade nur, ob das überhaupt was bringt und ob sich daran gegenüber normaler Nicht-static-Unterprogramme hinsichtlich der Semantik etwas ändert?

2.) static vs. extern:
Bzgl. des Zweckes. Gibt es einen entscheidenen Unterschied zwischen dem static- und extern-Spezifizierer?
Wann genau ist welcher zu bevorzugen?

3.) friend:
Kann mich mal einer zum friend-Spezifizierer aufklären?
Ich meine, ich sehe dahinter keinen Sinn, hebt dieser doch das Prinzip der Kapselung wieder auf?! Wozu gibt es diesen und kann mir mal jemand ein einfaches Beispiel zeigen, wo es Sinn macht, diesen einzusetzen? Die Beschreibungen und Beispiele im Netz und Büchern sind für mich mehr schlecht als recht.

Ich danke vielmals im Voraus!

MfG

Schlitzauge

Sers COM,
1.) static außerhalb von class:
Was für einen Sinn hat bzw. wie funktioniert eine static-deklarierte Funktion außerhalb einer Klasse? Bsp.:
[code="cpp"]static void Func1(void)
{
}

Als private Hilfsfunktion für eine globale foo() in der foo.hpp nebst foo.cpp.
Zum Beispiel würden in meiner malloc.hpp nur malloc/free stehen. Die malloc.hpp sie würde selber keine includes brauchen, außer einer Datei, die size_t besorgt. Und die malloc.cpp würde ballig mehr inkludieren und die malloc() worde die static growHeap() benutzen und eds gäbe auch globale Variablen und beliebige Freiheit. Nur müßte der Linker das halt nicht sehen.

Abgesehen davon, daß statt static besser namespace{

2.) static vs. extern:
Bzgl. des Zweckes. Gibt es einen entscheidenen Unterschied zwischen dem static- und extern-Spezifizierer?
Wann genau ist welcher zu bevorzugen?

Sie machen eher das Gegenteil. Da ist keiner zu bevorzugen, sie arbeiten Hand-in-Hand.

Schlitzauge schrieb:

3.) friend:
Kann mich mal einer zum friend-Spezifizierer aufklären?
Ich meine, ich sehe dahinter keinen Sinn, hebt dieser doch das Prinzip der Kapselung wieder auf?! Wozu gibt es diesen und kann mir mal jemand ein einfaches Beispiel zeigen, wo es Sinn macht, diesen einzusetzen? Die Beschreibungen und Beispiele im Netz und Büchern sind für mich mehr schlecht als recht.

friend benutzt man, wenn etwas "eigentlich" eine Methode sein müßte, aber als Methode nicht klappt. Hauptbeispiel der operator<<.

ostream& operator<<(ostream& o,Bruchzahl cons6& b){
   o<<b.zähler;
   if(b.nenner!=1){
      o<<'/';
      o<<b.nenner;
   }
   return o;
}

Weil Burchzahl nenner und zähler privat hat, kann der op<< zum friend werden, um genau ihm und keinem anderen Zugriff darauf zu geben.

3.) friend:
Kann mich mal einer zum friend-Spezifizierer aufklären?
Ich meine, ich sehe dahinter keinen Sinn, hebt dieser doch das Prinzip der Kapselung wieder auf?! Wozu gibt es diesen und kann mir mal jemand ein einfaches Beispiel zeigen, wo es Sinn macht, diesen einzusetzen? Die Beschreibungen und Beispiele im Netz und Büchern sind für mich mehr schlecht als recht.

friend ist eine Sache die man nicht oft braucht, aber wenn man es braucht, dann kann man damit die Kapselung verbessern, nicht aufbrechen.
friend schreibst du in die Klasse die Zugriff gewährt, jede Klasse kann also selbst entscheiden wer "darf" und wer "nicht darf".
Sogesehen wird also nichts aufgeweicht, denn wenn ich eine Klasse modifizieren kann, dann kann ich genau so gut gleich alle private: in public: umschreiben -- friend bringt hier also keine Verschlechterung.

Nur nebenbei: andere Sprachen bieten ähnliche Konstrukte an um das selbe zu erreichen, z.B. internal (C#) oder "package access" (Java). Der Unterschied dabei ist dass man mit internal bzw. "package access" genauer kontrollieren kann auf was zugegriffen werden darf, dafür weniger genau wer zugreifen darf.

OK, zurück zu "was soll das ganze?".

Beispiel: intrusive Datenstrukturen. Eine intrusive Map muss entweder Zugriff auf die im zu mappenden Element gespeicherte MapNode haben, oder die MapNode muss Zugriff auf die Map haben. Mit friend ganz einfach: die MapNode sagt friend Map und die Sache ist gegessen. Ohne friend muss man rumbasteln.

Etwas allgemeiner: wenn du zwei Klassen hast die eng zusammenarbeiten, für den User aber eben getrennte Klassen sein sollen, dann kann friend was bringen. Z.B. indem es dir ermöglicht ohne unnötigen Weiterleitungsfunktionen oder sonstige üble Tricks den Code einfach dort hinzuschreiben wo er hingehört.

Ein Beispiel dazu: Ein Renderer rendert, also gehört der Render-Code auch in den Renderer. Jetzt möchte der Renderer aber gerne auf Innereien einiger Renderables zugreifen -- z.B. weil er da drinnen irgendwelche Dinge cachen möchte. Vielleicht Texturen oder Shader oder Verwaltungsdaten für vom Renderer verwaltete Vertex-Buffer.
Also sagen die von der Library vordefinierten Renderables einfach friend Renderer , und er kann.
Ohne friend muss man auch hier entweder rumfrickeln, oder irgendwelche Implementierungsdetails allgemein zugänglich machen.

----

Nochwas: falls du das PIMPL Idiom kennst, dann denk man drüber nach was PIMPL und friend gemeinsam haben. Nämlich ziemlich viel wenn du mich fragst
(Und falls du es nicht kennt, dann schlag es nach.)
friend ermöglicht im Prinzip "PIMPL ohne Zeiger" . Dafür mit Inlining. Man könnte fast sagen: friend ist das bessere PIMPL.