warum dürfen friends das?

warum dürfen friends auf private-member einer klasse zugreifen? wäre es nicht besser, wenn friends nur auf protected-member zugreifen dürften?

queer_boy

warum?
du weißt schon, wozu protected da ist?

damit sie intim werden können

asc

acquaintance schrieb:

warum dürfen friends auf private-member einer klasse zugreifen? wäre es nicht besser, wenn friends nur auf protected-member zugreifen dürften?

Das Friend-Konzept ist nunmal so ausgelegt das es einen direkten Zugriff erlaubt. Eine Auslagerung in "protected" wäre wegen Vererbung aber nicht sinnvoll. Und ich bezweifel das es gut wäre wenn man die Zugriffsangaben noch auf die Spitze treibt (Denn dann Fehlt in C++ noch eine Begrenzung auf Namensräume, eine Begrenzung auf Klassen mit bestimmten Eigenschaften...)...

Irgenwann wären die Zugriffsangaben um jeden glücklich zu machen länger als der Eigentliche source

class A
{
    nurnamensraum_nurklassenmitbasisklassexyz_nurfreitagsoderwennichlusthabe: int foo();
}

cu André

queer_boy schrieb:

du weißt schon, wozu protected da ist?

um ableitenden klassen direkten zugriff auf member zu ermöglichen?

Eine Auslagerung in "protected" wäre wegen Vererbung aber nicht sinnvoll.

na gut, aber warum nicht? was hat denn die vererbung damit zu tun?
ich möchte gern wissen, welche gedanke dahinter steckt, dass friends der zugriff auf private- statt nur auf protected-member erlaubt sein muss.
entspräche denn x ist zwar nicht mit mir verwandt, soll aber so behandelt werden nicht eher der definition eines freundes als x ist zwar kein teil von mir, soll aber so behandelt werden?

queer_boy

dann definiere mal "freund".
eine friend -funktion ist für gewöhnlich teil der schnittstelle einer klasse. von daher kein problem.

asc

acquaintance schrieb:

Eine Auslagerung in "protected" wäre wegen Vererbung aber nicht sinnvoll.

na gut, aber warum nicht? was hat denn die vererbung damit zu tun?

Weil protected für die Vererbung gedacht ist und "friend" und Vererbung unterschiedliche Konzepte sind.

acquaintance schrieb:

ich möchte gern wissen, welche gedanke dahinter steckt, dass friends der zugriff auf private- statt nur auf protected-member erlaubt sein muss.

Wie gesagt, es handelt sich hier um unterschiedliche Konzepte. Wenn hätte man die Zugriffsoperatoren spezieller definieren müssen um diesen Anspruch gerecht zu werden. Vererbung dient dazu über die gleiche Schnittstelle verwendet werden zu können und um Funktionalität weitergeben zu können. "friend" dient dazu anderen Objekten eine Kontrolle zu erlauben um einerseits die Schnittstelle nach außen nicht für nicht-friends Aufweichen zu müssen und anderseits auch für eine Mögliche Trennung von z.B. Teilkonzepten ohne die eigentliche Klasse zu überfrachten.

So brauch man z.B. um ein Objekt serialisieren oder an einen Stream übergeben zu können, Kenntnisse vom Inhalt. Gleichzeitig will man aber nicht immer (bzw. es ist selten sinnvoll) Attribute in der Vererbungshierachie sichtbar machen. Nun hat man nur zwei Möglichkeiten:

Entweder man stellt jeden Mechanismus in der Klasse zur Verfügung, oder man lagert es wegen der Komplexität oder ähnlichen aus.

Ich habe z.B. Objekte die eine Datenbankentsprechung haben. Weil wir uns auf ein fixe Datenquelle (und Datenbanksystem) spezialisiert haben ist es nun so das die Funktionalitäten für einlesen/speichern etc. in die Objekte verlegt wurden sind (Ich hätte es wohl getrennt, aber dies ist ein historisches Relikt wo ich auch nichts ändern werde). Wenn ich nun aber ich sage mal nicht ein Element sondern eine Liste brauche, ist es selten sinnvoll die Objekte einzeln einzulesen. Sprich: Ich habe ein friend Deklariert der vollen Objektzugriff hat um die Member der Einzelobjekte über einen gemeinsamen Select zu füllen. Eine andere Option wäre es auch die Listengenerierung in die Klasse zu verschieben, ich sehe hier aber die Liste wie die anderen Objekte als eine Dateneinheit an, und stelle auf der Ebene auch die gleiche Funktionalität (wie Speichern etc.) zur Verfügung. Hier ist es aber einfach effektiver den Einzelmechanismus zu umgehen.

Diese Variante ist zugegebener Masen nicht unbeding das grüne von OO-Entwurf, aber wie ich privat entwickel steht auf einem anderen Zettel (Privat halte ich eine Schichtentrennung stärker ein als an der Arbeit und programmiere auch sauberer [da mir hier einige Mittel abgeblockt wurden sind oder durch die veraltete Umgebung nicht zur Verfügung stehen wie z.B. die STL]!).

cu André

ich glaub ich stehe auf dem schlauch. vielleicht stelle ich meine frage mal anders: warum gibt es die möglichkeit, per friend zugriffsrechte auf alle member zu erteilen, aber keine möglichkeit, dies nur für die protected-member zu tun, AUSSER per vererbung?
neben der freundschaft sozusagen die bekanntschaft.

"friend" dient dazu anderen Objekten eine Kontrolle zu erlauben um einerseits die Schnittstelle nach außen nicht für nicht-friends Aufweichen zu müssen und anderseits auch für eine Mögliche Trennung von z.B. Teilkonzepten ohne die eigentliche Klasse zu überfrachten.

richtig. und das ginge manchmal vielleicht noch besser und expliziter, wenn man durch 'friend' nicht gleich das gesamte innere der klasse zur verfügung stellen müsste.

asc

acquaintance schrieb:

"friend" dient dazu anderen Objekten eine Kontrolle zu erlauben um einerseits die Schnittstelle nach außen nicht für nicht-friends Aufweichen zu müssen und anderseits auch für eine Mögliche Trennung von z.B. Teilkonzepten ohne die eigentliche Klasse zu überfrachten.

richtig. und das ginge manchmal vielleicht noch besser und expliziter, wenn man durch 'friend' nicht gleich das gesamte innere der klasse zur verfügung stellen müsste.

Eben nicht. Für die von mir aufgeführten Punkte ist der Unterschied sehr relevant. Für das Füllen von Objekten bis enschließlich auf Ebene von Werten die von außen nicht geändert werden dürfen, würde protected nicht reichen. Warum? Weil ich dann anderseits auch der Vererbungshierachie den Zugriff gestatte, und dies nicht erwünscht ist.

Ja, ich könnte mir auch andere Sprachkonstrukte vorstellen die etwas diverenzierter Erlauben würden, etwas in der Art:

// Irgendeine nicht existente Sprache
class A
{
    private:
        [friend_read]
        string a;
        [friend_read,friend_write]
        string b;
}

Über den Sinn uns Unsinn von Friend kann man streiten, aber das Konzept hat nichts mit Vererbung zu tun, und somit auch nicht mit protected! Es geht wie gesagt um zwei grundverschiedene Angelegenheiten.

cu André