3. Frage bezüglich Zugriffsrechten

Frage bezüglich Zugriffsrechten

  • B

    Das beantwortet deine letzte Frage mit: Ja

    0
  • P

    Dann bedanke ich mich für die schnelle Antwort.

    0
  • F

    Du kannst von außerhalb der Klasse nicht auf private Member zugreifen, sondern nur auf die öffentlichen Member, also die Schnittstelle.
    Die öffentlichen Member selber, also Elementfunktionen oder auch Konstruktoren wie der Kopierkonstruktor können natürlich auf die privaten Member zugreifen.
    Wer soll den sonst drauf zugreifen können:D 😉

    Lg freeG

    0
  • K

    Das richtige Wort ist Sichtbarkeit, nicht Zugriffsrecht. In einem Haus sehe ich alles was drinnen ist, von draussen nur das am Fenster.

    0
  • O

    Datenkapselung nennt man das Ganze auch. Auf private Member hat nur die Klasse selbst zugriff. Lies dich etwas in OOP ein, dann wird dir das schnell klar...

    Omicron

    0
  • K

    Mal was ganz anderes: Deiner Klasse fehlt ein Zuweisungsoperator.

    String foo = "foo"; // Kopier-Initialisierung, OK
String bar = "bar"; // Kopier-Initialisierung, OK
foo = bar; // Zuweisung! --> foo.buffer == bar.buffer  Ooops!
    0
  • B

    knivil schrieb:

    Das richtige Wort ist Sichtbarkeit, nicht Zugriffsrecht. In einem Haus sehe ich alles was drinnen ist, von draussen nur das am Fenster.

    Das richtige Wort ist Zugriffsrecht. Private Member sind für jeden sichtbar. Ihr Name kann aber nur von Membern und Freunden der Klasse (der Klasse, nicht nur des jeweiligen Objekts) verwendet werden.
    Dass privates von aussen sichtbar ist, spielt an ein paar Stellen ein Rolle. z.B. müssen Parametertypen deklariert sein, auch wenn sie nie jemand von aussen benutzen kann und wird. Außerdem führt die Sichtbarkeit dazu, dass private Methoden bei der Namensauflösung brücksichtigt werden. Da name lookup und overload resolution vor der Prüfung der Zugriffsrechte stattfindet kann es zu recht überraschenden Compiler Fehlern kommen.

    class A
{
public:
  void f(float);
private:
  void f(int);
};

int main()
{
  A a;
  a.f(0); // wählt f(int) auch wenn f(float) gehen würde // -> kein zugriff
  retunr 0;
}
    0
  • K

    Die erstbeste Quelle: http://en.wikipedia.org/wiki/Class_diagram , http://de.wikipedia.org/wiki/Klassendiagramm unter Members.

    0
  • B

    Da geht es um UML.
    Ich weiß jetzt keinen Link. Es müsste aber eigentlich ein gotw dazu geben. Es gibt zumindest in "Exp. C++ Style" mindestens ein Item darüber.
    Privates ist in C++ sichtbar, es sei denn man pimpled es weg oder versteckt es irgendwie anders.

    0
  • ?

    brotbernd schrieb:

    Da geht es um UML.
    Ich weiß jetzt keinen Link. Es müsste aber eigentlich ein gotw dazu geben. Es gibt zumindest in "Exp. C++ Style" mindestens ein Item darüber.
    Privates ist in C++ sichtbar, es sei denn man pimpled es weg oder versteckt es irgendwie anders.

    Ich pimpel dich auch gleich weg.

    0
  • F

    krümelkacker schrieb:

    Mal was ganz anderes: Deiner Klasse fehlt ein Zuweisungsoperator.

    String foo = "foo"; // Kopier-Initialisierung, OK
String bar = "bar"; // Kopier-Initialisierung, OK
foo = bar; // Zuweisung! --> foo.buffer == bar.buffer  Ooops!

    Genau, da hat Krümelkacker recht.
    Merk dir die "großen drei" oder die "dreier Regel" welche besagt, dass man entweder Destruktor, Kopierkonstruktor und Zuweisungsoperator nicht selber erstellen braucht und die compilergenerierten verwenden kann, oder man muss alle drei selber erstellen.
    Muss man einen selber erstellen, sind die anderen beiden eigentlich auch so gut wie immer von nöten( Ausnahme ist ein virtueller Destruktor in der Basisklasse).
    Man braucht sie eigentlich immer, wenn man dynamisch Speicher zuweißt, also mit Zeigern rumhantiert.

    Hoffe konnte dir helfen.

    Lg freeG

    0
Anmelden zum Antworten