ich habe in meinem System einige Funktionen, die eigentlich nur vom System aufgerufen werden. Z.B. ruft eine Klasse Foo eine Methode Bar::methode() auf. Bar::methode() sollte eigentlich nicht vom Benutzer meines System direkt aufgerufen werden, aber manchmal braucht er das vielleicht doch.

Wie markiere ich so eine Funktion am besten? Nur in der Doku vermerken oder die Info in den Namen packen, zb die Methode _methode() nennen?

Das Design kann ich nicht groß ändern. Es gibt halt einige Funktionen, die der Benutzer nicht aufrufen SOLLTE. Aber wenn er genau weiß was er tut, dann ist es auch ok wenn er es macht. Ich glaub ich nehm den Unterstrich (hab ich schon in einigen Projekten gesehen)

Ich würde da auch einfach eine ganz normale öffentliche Funktion nehmen und dann einfach vermerken, dass sie nur mit Bedacht genutzt werden sollte. Schliesslich sollte beim programmieren immer mitgedacht werden..

Das ist das Problem/Segen an den eingebauten Mechanismen. Sie sind so strikt.

Ich würde da auch einfach eine ganz normale öffentliche Funktion nehmen und dann einfach vermerken, dass sie nur mit Bedacht genutzt werden sollte. Schliesslich sollte beim programmieren immer mitgedacht werden..

Finde ich schlecht. Dadurch verschlechtert man das Interface bzw. dessen Absicherung gegen Fehlbenutzung. Die Abhängigkeit bleibt dabei weiterhin bestehen. Es wird also nichts gewonnen. Ich würde dafür friends benutzen.

drakon schrieb:

Das ist das Problem/Segen an den eingebauten Mechanismen. Sie sind so strikt.

Ich würde da auch einfach eine ganz normale öffentliche Funktion nehmen und dann einfach vermerken, dass sie nur mit Bedacht genutzt werden sollte. Schliesslich sollte beim programmieren immer mitgedacht werden..

Finde ich schlecht. Dadurch verschlechtert man das Interface bzw. dessen Absicherung gegen Fehlbenutzung. Die Abhängigkeit bleibt dabei weiterhin bestehen. Es wird also nichts gewonnen. Ich würde dafür friends benutzen.

Das ist doch dann aber nicht mehr die gleiche Funktionalität. Wenn ich die Methoden private mache, dann hat der Benutzer ja garkeine Möglichkeit mehr sie manuell aufzurufen?

namespace foo_internals___use_with_caution 
{
}

packt?

Finde ich schlecht. Dadurch verschlechtert man das Interface bzw. dessen Absicherung gegen Fehlbenutzung.

C++ ist nicht dazu gedacht, irgendwas gegen Fehlbenutzung abzusichern. Siehe C++ FAQ LITE 7.6 und 7.7 .

Mache die besagten Funktionen oeffentlich und versehe sie mit einem Kommentar: only for internal use.

Und wenn man die Methode in

namespace foo_internals___use_with_caution 
{
}

packt?

Dann benutzt man einen reservierten Bezeichner (doppelte Underscores) :p

Dann benutzt man einen reservierten Bezeichner (doppelte Underscores) :p

Nur wenn diese am Anfang des Bezeichners auftauchen, ist es ein reservierter Bezeichner. In der Mitte oder am Ende ist es völlig egal.

Grüssli

Und was spricht dagegen, die Funktion protected zu machen, so dass man ableiten muss um an diese Funktion zu kommen? Denn wenn es ein äußerst seltener Spezialfall sein sollte, spricht eigentlich einiges für eine eigene Klasse.

Mir fallen da so ca 100 Gründe ein.
Ich mach sie jetzt einfach public und vermerke den "internal use" in der Doku.

Nur wenn diese am Anfang des Bezeichners auftauchen, ist es ein reservierter Bezeichner. In der Mitte oder am Ende ist es völlig egal.

Das verwechselst du wohl gerade mit einem einzelnen Underscore.

17.4.3.1.2 Global names schrieb:

Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (_ _) or begins with an underscore followed by an upper case letter (2.11) is reserved to the implementation for any use.

17.4.3.1.3 External linkage schrieb:

Each name having two consecutive underscores (2.11) is reserved to the implementation for use as a name with both extern "C" and extern "C++" linkage.

Finde ich schlecht. Dadurch verschlechtert man das Interface bzw. dessen Absicherung gegen Fehlbenutzung.

C++ ist nicht dazu gedacht, irgendwas gegen Fehlbenutzung abzusichern. Siehe C++ FAQ LITE 7.6 und 7.7 .

Mache die besagten Funktionen oeffentlich und versehe sie mit einem Kommentar: only for internal use.

Die C++ FAQ bestätigt meine Aussage.
Die Aussage ist "Encapsulation prevents mistakes, not espionage.". Und zwischen "private sehen können" und "gar nicht erst private machen" ist schon ein Unterschied, gelle?

Also knivel->Epic fail. Merke: Sicherheit != Sicherheit.

Es wird dort auch Folgendes über friends gesagt: friends

Öffentliche Interfaces sollte so sicher wie möglich gegen Falschbenutzung gesichert sein. Das gilt im verschärften Maße für Bibliotheken.
Was nicht öffentlich sein soll, soll nicht öffentlich sein. Das ist irgendwie in sich schon logisch. Wenn man Mittel hat, die Kapselung zu erhöhen, sollte man das auch tun.

Warum sollte man "only for internal use" ins öffentliche Interface schreiben, wenn man das besser über friends designen kann, und es dann eben auch wirklich nur intern benutzt werden kann? Du lässt ja auch nicht Deinen Darm aus Deinem After heraushängen, nur weil er gelgentlich mit der Toilette korrospondiert. Merke: Die Toilette ist Deine Freund.

Siehe auch Item 18 und 19 in "Effective C++".

PS: Die "interne" Funktion soll aber ganz offenslichtlich nicht wirklich intern sein. Also mache sie halt öffentlich.

Grüssli

class Foo
{
public:
  meh();
protected:
  methode();
};

class Bar : private Foo //statt Foo als Member zu haben.
{
  void baz()   
  {
    methode(); // (!)
  }
};

Ich denke wenns wirklich am Design nicht besser hinzubiegen ist (was ich erst glaube wenn ichs sehe), dann ist das mit der protected methode der richtige Weg - und zwar mit private Vererbung:

class Foo
{
public:
  meh();
protected:
  methode();
};

class Bar : private Foo //statt Foo als Member zu haben.
{
  void baz()   
  {
    methode(); // (!)
  }
};

Und wieso ist das besser als friend ? Die Bindung ist doch noch viel stärker.

Und wieso ist das besser als friend ? Die Bindung ist doch noch viel stärker.

Nope. Friend-Bindung ist noch stärker als Vererbung (weil friend eben auch Zugriff auf private Elemente erlaubt, Vererbung nicht).

Tachyon schrieb:

Und wieso ist das besser als friend ? Die Bindung ist doch noch viel stärker.

Nope. Friend-Bindung ist noch stärker als Vererbung (weil friend eben auch Zugriff auf private Elemente erlaubt, Vererbung nicht).

Okay, da ist was dran.

@Tachyon: Mach mal hier lieber nicht auf dicken Macker. So der Oberchecker biste ja offenbar auch nicht, gelle?

@Tachyon: Mach mal hier lieber nicht auf dicken Macker. So der Oberchecker biste ja offenbar auch nicht, gelle?

Im Gegensatz zu einigen anderen hier lasse ich mich mit brauchbaren Argumenten aber i.d.R. belehren.

Tachyon schrieb:

Also knivel->Epic fail

unterlässt.

Ich würde also sagen: einfach private machen, und per "friend" drauf zugreifen lassen.

Sollte irgendwann mal der Fall auftreten, dass die Funktion von aussen benötigt wird, kannst du die Funktion dann immer noch public machen.