Interne Funktion

knivil

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.

Registrierter Troll

SeppJ schrieb:

Und wenn man die Methode in
namespace foo_internals___use_with_caution 
{
}
packt?

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

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.

Dravere

Registrierter Troll schrieb:

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

hmmmmm schrieb:

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.

Registrierter Troll

Dravere schrieb:

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.

Tachyon

knivil schrieb:

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.

Dravere

@Registrierter Troll,

Ich muss ein paar Namen ändern gehen
Danke für die Aufklärung, hatte das anders im Kopf.

Grüssli

pumuckl

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(); // (!)
  }
};

Tachyon

pumuckl schrieb:

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.

pumuckl

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

Tachyon

pumuckl schrieb:

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.

Wie ich bereits sagte, ich mach die Methode public und vermerke in der Doku, dass man sie eher nicht verwenden sollte. Aber eben KANN. Drum macht private absolut keinen Sinn. Vererbung gleich 3mal nicht, da die Klassen nicht zum Ableiten designed sind und es auch nie werden.

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

Tachyon

frager schrieb:

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

Noch besser wärs, wenn du im Forum Kindereien wie

Tachyon schrieb:

Also knivel->Epic fail

unterlässt.

hustbaer

Die Beschreibung "User sollte nicht, darf aber wenn er genau weiss was er tut" deutet IMO auf einen Design-Fehler hin. Natürlich kann man das nicht 100% sagen ohne den speziellen Fall zu kennen, aber meist ist es so.

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.

Caster

Oft ist es so, dass man diese öffentlichen Methoden nicht zwingend braucht. Aber wenn man weiß was man tut, kann man dadurch Sachen effektiver implementieren, wenn man zB. selber im internen Puffer rumpfuschen kann.