Friends-von Klassen

hi
mir hat heute jemand gesagt das friends einer klasse anzulegen, nicht direkt "schlechter stil" wäre aber nicht so schön... also wenn ich funktionen schreibe die als friend einer klasse arbeiten...
findet ihr das auch bzw stimmt das?

er meinte halt das ich dadurch das ganze private, public prinzip "zerschießen" würde und dadurch der code der entsprechenden klassen und funktionen schlecht nachvollziehbar wäre...

aber ich finde ganz im gegenteil ist es dadurch ja sogar noch eindeutiger ...
weil dadurch ist ja klar erkennbar das diese funktion ein friend ist...

nutzt ihr "friend" oder sollte ich die entsprechenden teile der klasse dann einfach "public" machen? (sowie auf anraten hin...)

ist vll auch ne blöde frage sry...

krümelkacker

Smiley1 schrieb:

er meinte halt das ich dadurch das ganze private, public prinzip "zerschießen" würde und dadurch der code der entsprechenden klassen und funktionen schlecht nachvollziehbar wäre...

Das sehe ich nicht so. Die friend-Deklarationen sind ja innerhalb der Klasse. Es ist immer also klar, wer Zugriff auf private Elemente hat. In anderen Sprachen händelt man das sogar noch liberaler: Da sind automatisch alle "miteinander befreundet", die in demselben Package oder Modul definiert werden.

Smiley1 schrieb:

aber ich finde ganz im gegenteil ist es dadurch ja sogar noch eindeutiger ...
weil dadurch ist ja klar erkennbar das diese funktion ein friend ist...

Genau.

Smiley1 schrieb:

nutzt ihr "friend" oder sollte ich die entsprechenden teile der klasse dann einfach "public" machen? (sowie auf anraten hin...)

Ja, ich nutze friend da wo es Sinn macht. Allerdings hat ein gewisser Anteil gar nichts mit Zugriff auf private Elemente zu tun. friend erlaubt es dir auch, eine "freie Funktion" innerhalb einer Klasse zu definieren, die dann per ADL gefunden werden kann. Das hat bei templatisierten Klassen u.U. einen Vorteil, gerade bei der Operatorüberladung hinsichtlich impliziten Umwandlungen für Argumente. Die Alternative dazu wären Funktionstemplates, wobei die Template Argument Deduction aber kaum implizite Umwandlungen zulässt. Das sind so Tricks aus der C++ Trickkiste.

Jockelx

Alle diese das-darfst-du-nicht Regeln machen für sich alleine keinen Sinn.
Wichtig ist die Begründung, warum man das in der Rgel nicht machen soll und dann kann man für sich entscheiden, ob diese im allgemeinen vielleicht gute Regel auch auf das eigene Problem zutrifft.

friend-darfst-du-nicht kenne ich gar nicht. Ich nutze es, aber selten.

ok vielen dank für die antworten , das hat mir sehr geholfen.
denk mal ich nutzt es auch...
ich verstehe da eig auch nicht was es "schlecht nachvollziehbar machen" soll...
danke ich habt mich nur nochmal bestätigt ...
lg

Skym0sh0

Jockelx schrieb:

friend-darfst-du-nicht kenne ich gar nicht. Ich nutze es, aber selten.

Ich denke mal, das klassische Beispiel ist:

class Widget
{
	int myX;

public:
	friend std:ostream& operator<<(std::ostream& os, Widget const& w)
	{
		os << w.myX;
		return os;
	}

	friend std:istream& operator>>(std::istream& is, Widget & w)
	{
		is >> w.myX;
		return is;
	}
};