Ich verstehe das mit dem friend-Schlüsselwort nicht.
Ich habe eine Klasse A und eine Klasse B.
A hat eine private Methode, auf die aber Klasse B zugreifen können soll.
Wie muss ich das also machen?

Grüße, pktm

aber friend klassen sollte man eher nicht verwenden weil das ausschließlich ein c++ feature ist und nicht in java und auch nicht in c# vorhanden, ka wie es mit anderen programmiersprachen aussieht aber das sind die großen (VB hat es glaub ich auch nicht)

und wenn man sich das angewöhnt und man auf ein mal was anderes als c++ programmiert ist das schlecht

du sagst in klasse a "friend B" oder "friend class B" (weiss die syntax nicht auswendig)

aber friend klassen sollte man eher nicht verwenden weil das ausschließlich ein c++ feature ist und nicht in java und auch nicht in c# vorhanden, ka wie es mit anderen programmiersprachen aussieht aber das sind die großen (VB hat es glaub ich auch nicht)

und wenn man sich das angewöhnt und man auf ein mal was anderes als c++ programmiert ist das schlecht

Ah ok. Naja, dass es C++-typisch ist ist nicht so mein Problem, weil es ja ein C++-Programm ist
In Java/Perl oder was mir sonst noch so über den Weg läuft würde ich dafür einfach öffentliche Methoden nehmen.
Nur wenn man schon mal die Möglichkeit hat sowas zu benutzen...

Danke & Grüße, pktm

Vevusio schrieb:

aber friend klassen sollte man eher nicht verwenden weil das ausschließlich ein c++ feature ist und nicht in java und auch nicht in c# vorhanden, ka wie es mit anderen programmiersprachen aussieht aber das sind die großen (VB hat es glaub ich auch nicht)

Diese Argumentation finde ich sehr nützlich, jetzt benutzt sicher keiner mehr friend, weil es ja in anderen Programmiersprachen nicht existiert... Ist ja genau gleich mit überladenen Operatoren, die es z.B. in Java nicht gibt und deshalb auch kein Schwein in C++ verwendet

Vevusio schrieb:

und wenn man sich das angewöhnt und man auf ein mal was anderes als c++ programmiert ist das schlecht

Das könnte man wohl bei sehr vielen Teilaspekten von C++ sagen. Das kann ich jedoch nicht als Grund für deren Nicht-Verwendung akzeptieren, zumal viele C++-Programmierer gar nicht nebenan noch drei weitere Sprachen betreiben und sich deshalb auch nicht sorgen müssen.

aber friend klassen sollte man eher nicht verwenden weil das ausschließlich ein c++ feature ist und nicht in java und auch nicht in c# vorhanden, ka wie es mit anderen programmiersprachen aussieht aber das sind die großen (VB hat es glaub ich auch nicht)

Sorry, aber diese Aussage ist doch völliger Schwachsinn.;)

Es gibt Gründe, warum es verschiedene Programmiersprachen. Sonst gäbe es ja nur eine. Und wenn man eine Sprache hat, ist es nicht der Sinn einen Programmierstil oder Angewohnheiten von anderen Sprachen darauf übertragen zu wollen. Man soll die Sprache so benutzen, wie es der Sinn davon ist und nicht, wie man es gewohnt ist. Ansonsten kann man wieder auf der Sprache programmieren, die man voher hatte.

operatoren überladen gibt es in java zwar nicht aber statt statt
a = a + b
kann man einfach schreiben a.add(b)

genauso fuer alle anderen operatoren, das laesst sich ganz leicht durch methoden ersetzen

friends verwenden ist aber nicht sowas einfaches sondern es kann sehr stark in die programmstruktur eingreifen und man kann sich angewohnen oft "design patterns" zu verwenden welche nur in c++ funktionieren

dieses keyword wurde in den neuen sprachen ja nicht zum spaß abgeschafft

wenn ihr andere argumente wollt als "das gibts nur in c++"
- es erhoeht die kopplung zwischen zwei klassen was allgemein schlecht ist
- es verletzt die kapselung was schlecht ist

und wenn man sich irgendwelche anti-friend artikel durchliest findet man sicher viel mehr

wo ist jetzt der grosse unterschied?

was deine 2 angeblichen nachteile angeht: friend kann oft eingesetzt werden um eine starke koppelung zu verhindern, nämlich dort ein paar klassen von natur aus stark gekoppelt sein müssen (oder sollten, aus performance gründen) - mit friend kann man die nämlich schön gegenüber der aussenwelt "zumachen".

geht wie gesagt in java/c# auch, aber dort haben dann gleich alle klassen eines moduls oder namespaces oder was auch immer zugriff.

ich finde friend da wesentlich besser.

und zuletzt: in sprachen die kein friend kennen wird das prinzip auch oft verwendet, nur werden dort dann naming-conventions und/oder kommentare verwendet um die funktionen als "intern" zu markieren.

mit detail namespaces ist es ja im prinzip auch dasselbe, bloss hier umgekehrt: hier fehlt c++ das feature eine klasse als "modul-intern" zu markieren, deswegen packt man sie in einen detail namespace.

anders gesagt: ich finde deinen rat nicht gut

was deine 2 angeblichen nachteile angeht: friend kann oft eingesetzt werden um eine starke koppelung zu verhindern, nämlich dort ein paar klassen von natur aus stark gekoppelt sein müssen (oder sollten, aus performance gründen) - mit friend kann man die nämlich schön gegenüber der aussenwelt "zumachen".

ich stimmte dir zu 100% zu.
friends werden im allgemeinen als teil des interface der jeweiligen klasse gesehen, wie operatoren zb. warum sollte nicht eine zweite klasse dieses interface abstrahieren dürfen?

Vevusio schrieb:

wenn ihr andere argumente wollt als "das gibts nur in c++"
- es erhoeht die kopplung zwischen zwei klassen was allgemein schlecht ist
- es verletzt die kapselung was schlecht ist

auch dem stimme ich zu.

nur sollte die schlussfolgerung nicht lauten, friend nicht einzusetzen. vielmehr muss man hier beide seiten in erwägung ziehen: verletzt friend die kapselung und gibt es eine andere, bessere art, die gewünschte funktionalität zu erreichen? dann spricht nichts dagegen, friend nicht zu verwenden. allerdings stellt sich genauso die frage, ob man friend aufgeben sollte, nur weil man es aus anderen sprachen nicht gewohn ist. im endeffekt sollte man über einen wohlbedachten einsatz von friend nicht streiten.

um mich mal auf das Gute zu konzentrieren:

Vevusio schrieb:

...
aber friend klassen sollte man eher nicht verwenden weil ...

eine solche "Komplettöffnung" für eine andere Klasse nur selten notwendig ist. Stattdessen genügt es oft, wenn einzelne Funktionen "befriendet" werden und man damit eine klare Schnittstelle zwischen den Klassen hat.

Bei einer "Friendklasse" finde ich den Nachteil, dass man die beiden implementationstechnisch sehr eng koppelt ... sobald man die interne Implementation der "befriendenden" Klasse ändert, muss man die Implementierung aller "Friends" durchsehen, ob die damit ein Problem haben (weil sie ja theoretisch auf alles zugreifen können). Da ist es einfacher, wenn es sich nur um klar definierte Funktionen handelt.

Wohlgemerkt: Ich meine nicht, dass Friendklassen immer vermieden werden sollen, sondern nur eher !
Wie so oft gibt es für jede Richtlinie wohlbegründete Ausnahmen.

Gruß,

Simon2.