Hier steht: http://www.cpp-tutor.de/cpp/le09/klassen.html

Hierzu erhält die Memberfunktion eine Referenz auf das zu kopierende Objekt, das natürlich ebenfalls der Klasse Window angehört. Obwohl nun die Eigenschaften des übergebenen Objekts gegen den direkten Zugriff geschützt sind (private), kann die Memberfunktion CopyData(...) auf die geschützten Daten des übergebenen Objekts zugreifen.

Aber CopyData kann auch so auf width zugreiffen

#include <iostream>
using namespace std;

class Window
{
short width;

public:

   int CopyData( );

   Window :: Window ()
   {
      width = 2;
   }

};

int Window::CopyData( )
{

   cout<<        width << endl;
}

int main ()
{
Window w;
w.CopyData( );

system("PAUSE");
}

Ist das nicht irgendwie sinnlos so ?
Würde man die Eigenschaften einem anderem Objekt übergeben könnte das ja noch Sinn machen aber so ??

#include <iostream>
using namespace std;

class Window
{
short width;

public:

   int CopyData( Window& source );

   Window :: Window ()
   {
      width = 2;
   }

};

int Window::CopyData( Window &source)
{
   width = source.width;

   cout<< source.width << endl;;
   cout<<        width << endl;
}

int main ()
{
Window w;
w.CopyData( w);

system("PAUSE");
}

Der Sinn ist ein anderer:
Er sagt potentiellen Benutzern Deiner Klasse (das musst Du ja nicht selbst sein), dass die Daten nicht benutzt werden sollen.

Beispiel:
Es gibt eine Klasse, die irgendwie mit Winkeln und trogonometrischen Funktionen rumhantiert.
Die erste Version sieht so aus:

class AngleClass
{
public:
    AngleClass(float angle) : m_angle(angle){} //erwartet Winkel in Grad

    float getAngleDeg() const { return m_angle; } //gibt Winkel in Grad
    float getAngleRad() const { return m_angle / 180 * PI; } //gibt Winkel in Radiant

    void doSomething()
    {
        std::sin(getAngleRad()) * //...jede menge Berechnungen
        //...
    }
private:
    float m_angle;
};

Jetzt fällt Dir auf, dass Du klassenintern eigentlich nur Rad brauchst. Du konvertierst Dir jetzt den Winkel im Konstruktor in Rad und arbeitest dann intern damit:

class AngleClass
{
public:
    AngleClass(float angle) : m_angle(angle / 180 * PI){} //erwartet Winkel in Grad

    float getAngleDeg() const { return m_angle / PI * 180; } //gibt Winkel in Grad
    float getAngleRad() const { return m_angle; } //gibt Winkel in Radiant

    void doSomething()
    {
        std::sin(m_angle) * //...jede menge Berechnungen
        //der Winkel muss jetzt nicht mehr fuer jede trig. Funktion in Rad. konvertiert werden
        //...
    }
private:
    float m_angle;
};

Für einen Benutzer Deiner Klasse würde sich nichts ändern. Konstruktor und Funktionen verhalten sich nach wie vor gleich, obwohl sich die interne Repräsentation des Winkels geändert hat.

Wäre m_angle public gewesen, hätte ein fauler Benutzer der Klasse direkt auf die Variable zugreifen können (etwas weniger Schreibaufwand). Wäre er jetzt zur Version 2 der Klasse gewechselt, hätte sein Programm plötzlich nicht mehr korrekt funktioniert.

Was hat das mit meinem Beispiel zu tun ?

Das sagt mir überhaupt gar nichts.

Was hat das mit meinem Beispiel zu tun ?

Es soll dir den Nutzen von private klarmachen. Private ist nämlich nicht dazu da, die Klasse vor sich selbst zu schützen, sondern vor äußeren Einflüssen.

Wenn du nun eine Instanz von Window erstellst, wie du es ja getan hast:
Window w;

Und dann mit w.CopyData() die Funktion aufrufst, dann brauchst du w nicht übergeben, da CopyData sich ja schon auf w bezieht. Du rufst die Funktion ja auch mit w.Func() auf.

#include <iostream>

class A
{
private:
	int value_;

public:
	A(int value)
	{
		value_ = value;
	}

	void Print()
	{
		std::cout << "A::value_ = " << value_ << std::endl;
	}

	void Set(int value)
	{
		value_ = value;
	}
};

int main()
{
	A a(100); // Instanz von A erstellen. Wert für value_ soll 100 sein.

	a.Print(); // Den Wert ausgeben

	a.Set(200); // Den Wert ändern

	a.Print(); // Den Wert erneut ausgeben

	a.value_ = 10; // error C2248: "A::value_": Kein Zugriff auf private Member, dessen Deklaration in der A-Klasse erfolgte.
}

Das sagt mir überhaupt gar nichts.

Wo liegt denn das Problem?

obj schrieb:

Was hat das mit meinem Beispiel zu tun ?

Deine Frage bezog sich auf den Sinn von Zugriffsrechten, im Speziellen von private .
In Deinem Beispiel kommen die Vorzüge, die es mitbringt, wenn man Dinge private deklariert nicht zum Tragen.
In dem von Dir verlinkten Kurs wird nur erklärt, was private rein technisch tut. Der Sinn dahinter wird aber nur mit einem schwammigen Satz erklärt. Deahalb ein anderes Beispiel...

Window w;
w.CopyData( w);

Ich sehe da noch immer keinen Sinn drin.

Naja vielleicht erkenn ich den ja irgendwann oder auch nicht.

#include <iostream>
using namespace std;

class AngleClass
{

public:
    AngleClass(float angle) : m_angle(angle / 2 ){}

    float getAngleDeg() const { return m_angle / 180; }
    float getAngleRad() const { return m_angle; }

private:
           float m_angle;  // <-- auch wenn das public ist funktioniert es ...

};

int main ()
{
AngleClass w(90);

int ret;

ret = w.getAngleRad();

cout<<ret<<endl;

system("PAUSE");
}

Mit public kannst du diese Verschlossenheit aufheben.

class A
{
 public:
  int x;
};
// ...
A a;
a.x = 10;

Würde gehen. Mit private funktioniert das nicht mehr. Der Sinn? Kapselung der Daten.

Die Klasse selber hat aber unabhängig von public und private Zugriff auf die Variable. Denn sie gehört ihr ja sozusagen.

Angle a;
a.value = 960;

Juppidu, unsere geforderte Eigenschaft von 0<=value<360 ist ungültig! Darum machen wir "value" private, damit solche Sachen unter der Kontrolle der Klasse bleiben.

Ist das jetzt klarer?

float m_angle;  // <-- auch wenn das public ist funktioniert es ...

Klar funktioniert es. Nun stell Dir vor, m_angle wäre public. Jetzt gibt es einen faulen Benutzer der Klasse, der direkt auf m_angle zugreift (es geht ja und spart Tipperei). In seiner Version wird in m_angle der Winkel in Grad gespeichert.

Er legt das Objekt so an:

AngleClass a(180); // m_angle hat den Wert 180

Nun greift er munter auf m_angle zu (am Besten an vielen Stellen im Code, über viele Dateien verteilt):

functionOfTheStupidUser(a.m_angle); //erwartet Winkel in Grad, also den Wert 180

Jetzt denkt sich der Entwickler von AngleClass (also eine andere Person), hey, wenn ich intern mit Radiant anstatt mit Grad rechne, ist die Klasse viel effizienter und der Code wird einfacher. Er ändert also entsprechend.

Beim doofen Benutzer:

functionOfTheStupidUser(a.m_angle); //erwartet Winkel in Grad, jetzt sind es aber Radiant, also der Wert pi -> die Funktion macht Mist

Jetzt muss man erstmal merken, dass etwas nicht stimmt und woher das Problem kommt. Wenn man Pech hat, ist schon ein Flugzeug abgestürzt.

Hätte der doofe, faule Benutzer die getter Funktion AngleClass::getAngleDeg() benutzt, würde jetzt immer noch der Wert 180 an die Funktion functionOfTheStupidUser übergeben werden. Völlig unabhängig von der internen Darstellung.
Durch private verbietest Du nun, das Anwender auf der internen Darstellung rumhampeln. Diese müssen brav die Getter und Setter benutzen, und bei denen kannst Du (als Entwickler der Klasse) sicherstellen, dass immer das richtige herauskommt. Unabhängig davon, was intern passiert.

also ich finde das ganz einfach:
- Jeder (naja - fast) darf mir die Hand geben
- Nur MEINE Hand darf meinen Dödel anfassen (oder andere Körperteile, dmit denen es mir möglich ist).

Diese Trennung finde ich gut. ... und ich sehe keinen Grund dafür, meiner Hand den Zugriff auf meinen Dödel prinzipiell zu verbieten.

Gruß,

Simon2.

...

ROFL ... you made my day

Simon2 schrieb:

...

ROFL ... you made my day

Das ist eine Übersetzung aus dem Englischen, im Original wird es noch deutlicher:

Only you and your friends may touch your private parts.
Neither your children nor your friends' children may not touch your privates.

Aber es ging mir um das objekt w was in CopyData steht: w.CopyData( w);

Das ich da in diesem Beispiel keinen Sinn sehe.

Das man die Variable width im Hauptprogramm z.b. nciht so ändern kann das hab ich verstanden; main () { Window w; w.width = 100; } <-- Geht ja nicht weil width Private ist.

#include <iostream>
using namespace std;

class Window
{
short width;

public:

   int CopyData( Window& source );

   Window :: Window ()
   {
      width = 2;
   }

};

int Window::CopyData( Window &source)
{
   width = source.width;

   cout<< source.width << endl;;
   cout<<        width << endl;
}

int main ()
{
Window w;
w.CopyData( w);

system("PAUSE");
}

class Klasse {
State state; // hierfür gibt es keinen getter oder setter, das ist nur eine intern genutzte Variable
public:
    Klasse(const Klasse& other); // Und wie sollen wir hier vorgehen, wenn state auch kopiert werden können soll?
};

Die Klasse "Window" hat ja auch "CopyData" im Griff, kann damit aufpassen dass nichts schlechtes geschieht.

...
Only you and your friends may touch your private parts.
Neither your children nor your friends' children may not touch your privates.

Das finde ich gut (und auch besser als meins) - kannte ich allerdings nicht.
(obwohl mir natürlich der Ausdruck "my private( part)s" schon bewusst war).

Mir war allerdings hier im Kontext wichtig, dass überhaupt die eigenen public Funktionen auf die "privates" zugreifen dürfen. Das war hier ja IMHO die Verständnisschwierigkeit des Fragestellers...

padreigh schrieb:

Simon2 schrieb:

...

ROFL ... you made my day

Gern geschehen.

Danke,

Simon2.

Only you and your friends may touch your private parts.
Neither your children nor your friends' children may not touch your privates.

Ist das da nicht ein 'not' zu viel?