// rational.h
/*
//*/
#ifndef RATIONAL
#define RATIONAL

class Rational
{
private:
    int m_zaehler;
    int m_nenner;
    // ...

public:
    Rational(int zaehler, int nenner);
    Rational operator*(Rational rhs);
    // ...
};
#endif

Die Funktion operator* habe ich folgendermassen geschrieben:

Rational Rational::operator*(Rational rhs)
{
    int resultZaehler = m_zaehler * rhs.m_zaehler;
    int resultNenner = m_nenner * rhs.m_nenner;
    Rational result(resultZaehler, resultNenner);
    return result;
};

Soweit sogut, in einer main() kann ich das ganze testen und es funktioniert - aber warum? rhs.m_nenner und rhs.m_zaehler duerften doch als "private" deklariert, eigentlich gar nicht zugaenglich sein, oder? Habe ich etwas bei der "private" Deklaration falsch gemacht?

Rational Rational::operator*(Rational rhs)

kannst du auch auf deine privat member zugreifen. Sobald du aber ausserhalb deiner Klasse versuchst darauf zuzugreifen z.b in deiner Main durch

Rational r;
cout<<r.m_zaehler<<endl;

wird dir der Compiler ne abfuhr erteilen und sagen, dass m_zaehler privat ist.

MFG
chewbo

Kann man die eigentlich auch noch aendern (falls man aus versehen nicht als const uebergibt)?

Irgendwie dachte ich, es sei logischer, nur das Objekt selbst und nicht Objekte der gleichen Klasse koennten auf private zugreifen. Aber dann wuerde man wohl Probleme mit de copyconstructor kriegen...

Komisch finde ich, dass das z.B auch in Bruce Eckels Thinking in C++ nicht erwaehnt wird. Oder hab ichs ueberlesen?

Kann man die eigentlich auch noch aendern (falls man aus versehen nicht als const uebergibt)?

Ja kann man. Wieso ist das komisch? Es wird doch nicht per Objekt gekapselt sondern auf Klassenebene.

grüße

Die Kapselung bezieht sich auf die Klasse, nicht auf das Objekt.

Du BRAUCHST diese Möglichkeit für Operatorüberladung, Kopierkonstruktor und Vergleichsmethoden, möglicherweise auch noch an anderen Stellen.

Das ist also durchaus beabsichtigt und kein Fehler.

Es ist zwar kein Muss, aber du solltest binäre Operatoren besser auf Namensraumebene überladen und nicht auf Klassenebene.

class Rational
{
    //...
};

Rational operator*(const Rational& lhs, const Rational& rhs)
{
    //...
}

Und sofern der Zugriff auf private Member notwendig ist, muss noch eine friend Deklaration innerhalb der Klasse stehen.

class Rational
{
    //...
    friend Rational operator*(const Rational& lhs, const Rational& rhs);
    //...
};

Das hat den Vorteil, dass hier Konstruktoren für _beide_ Operanden implizit herangezogen werden können, bei der Klassenimplementation ist das nur beim rechten Operand der Fall. Und normalerweise will man ja, dass sowohl 'a op b' als auch 'b op a' funktioniert.

Kam mir auch irgendwie konmisch vor, dass man scheinbar ueber ein Objekt einer Klasse auf private Elemente eines anderen Objekts dieser Klasse zugreifen kann.

Kann man die eigentlich auch noch aendern (falls man aus versehen nicht als const uebergibt)?

Irgendwie dachte ich, es sei logischer, nur das Objekt selbst und nicht Objekte der gleichen Klasse koennten auf private zugreifen. Aber dann wuerde man wohl Probleme mit de copyconstructor kriegen...

Komisch finde ich, dass das z.B auch in Bruce Eckels Thinking in C++ nicht erwaehnt wird. Oder hab ichs ueberlesen?

Wie meine Vorredner, hier noch ein Beispiel, um zu verdeutlich, wie ungünstig eine Kapselung auf Objektebene wäre:

class Foo
{
    int foo_;
public:
// ...
    int select_foo(const Foo& other) const
    {
        const Foo& r = rand() % 2 ? *this : other;
        return r.foo_;
    }
};

Offensichtlich könnte eine Verletzung auf Objektebene nur während der Laufzeit festgestellt werden und auch dann müsste man prüfen, ob nicht other zufällig auf dasselbe Objekt wie *this verweist. Jedenfalls ist eine Prüfung zur Laufzeit statt beim Compilieren etwas, dass wir gerade vermeiden wollen.

Naja, habs dann ja später durch Copyconstructor und co rausgefunden. Bin aber froh, dass es mir wenigstens nicht alleine so ergangen ist.

const Rational operator*(const Rational& lhs, const Rational& rhs);

Wenn da so :

const Rational operator*(const Rational& lhs, const Rational& rhs);

Begründung?

Wenn da so :

const Rational operator*(const Rational& lhs, const Rational& rhs);

Durchaus möglich, mache ich meistens auch so. Ist aber keinesfalls zwingend. Genauso wenig wie die Argumente per Referenz zu übergeben. Alexandrescu hat zB mal was dazu geschrieben. Es ging hier ja lediglich um das Prinzip zwischen Klassen- und Namensraumüberladung von binären Operatoren. Die letztendliche Implementation hängt sowieso vom jeweiligen Szenario ab.

Soweit müsste man gar nicht gehen. Private/protected Zugriff auf Objektebene würde in C++ nur Sinn machen, wenn man prüft, ob ein Member zu this gehört oder nicht. In deinem Fall gehört foo_ zu r und müsste somit einen Compilerfehler verursachen. Die Laufzeitbindung von r ist daher nicht wirklich entscheidend.

Es ist doch das selbe Objekt. r und this haben die selbe Adresse, zeigen auf den selben Speicherbereich, also sind es die selben Objekte. Es wird ja kein neues Objekt, sondern nur ein Alias für das selbe Objekt erzeugt.

Genauso wenig wie die Argumente per Referenz zu übergeben. Alexandrescu hat zB mal was dazu geschrieben.

Warte mal. Alexandrescu bezog sich dabei auf eine Kopiersemantik. D.h. (wenn Du das gleiche meinst wie ich, wovon ich aber ausgehe) er hat keineswegs irgendwo geschrieben, dass man Argumente nicht per Referenz übergeben sollte -- außer für den Fall, dass man sie danach eh kopiert. Folgender Code ist natürlich ein wenig unsinnig:

void foo(T const& v)
{
    T tmp = v; // Kopie
    // ...
}

Dann hätte man nämlich gleich eine Kopie übergeben können. Aber ansonsten sollte man bei non-PODs durchaus immer Referenzen verwenden.

DEvent schrieb:

Es ist doch das selbe Objekt. r und this haben die selbe Adresse, zeigen auf den selben Speicherbereich, also sind es die selben Objekte. Es wird ja kein neues Objekt, sondern nur ein Alias für das selbe Objekt erzeugt.

Ich habe ja auch nicht gesagt, dass das, was camper geschrieben hat, falsch ist. Das Beispiel widerstrebt nur dem Design von C++, also dem statischen Typsystem und der daraus resultierenden statischen Fehlerbehandlung. Und auf der Basis, also wo Laufzeitbindung eine Rolle spielt, kann man eben keinen Memberzugriff auf Objektebene spezifizieren. Alles was bleibt, ist der Sichtbarkeitsbereich. Und dort spielt die Laufzeitbindung dann keine Rolle mehr.

Begründung?

Damit zB sowas nicht möglich ist:

Rational a,b,c;
//...
a*b = c;

Bei einem nicht-Konstanten Rückgabewert würde dies funktionieren...
Aber ich denke mal du weißt das schon und willst mich jetzt eines besseren Belehren

camper schrieb:

Begründung?

Damit zB sowas nicht möglich ist:

Rational a,b,c;
//...
a*b = c;

Bei einem nicht-Konstanten Rückgabewert würde dies funktionieren...

Aber ich denke mal du weißt das schon und willst mich jetzt eines besseren Belehren

Keineswegs. Ich meine, die Frage, ob man ein derartiges Konstrukt überhaupt verhindern muss, sollte jeder selbst entscheiden. Ich habe selten das Bedürfnis, so etwas zu schreiben.
Wir können Vorkehrungen wegen Murphy treffen, aber gegen Machiavelli ist in C++ sowieso kein Kraut gewachsen.
Immerhin, ein Konstruktion der Art

a*b*=c

an Stelle von

a*b*c

kann für eigene Typen durchaus sinnvoll sein, um ein paar unnötige Temporaries loszuwerden, und wir das ganze nicht gerade durch Expressiontemplates lösen.

Jeh genauer man die Bedingungen seiner Funktionen definiert (im Bezug auf public/private ebenso wie const correctness), desto mehr kann einem der Compiler dabei unterstützen Fehler zu verhindern. Für die reine Funktionalität sind die meisten dieser Sachen letzten Endes belanglos. Will sagen, Du kannst ebenso alles public machen und komplett auf const verzichten, laufen wird das Programm dann auch. Nur erhöhst Du damit die Chancen, daß Fehler unbemerkt bleiben... Bis sie dann in Produktion aufschlagen...

Keineswegs. Ich meine, die Frage, ob man ein derartiges Konstrukt überhaupt verhindern muss, sollte jeder selbst entscheiden.

Ja und wenn ich schon die Möglichkeit habe, solche Fehlerquellen zu ellimnieren, dann versuche ich es auch...

a*b*=c

Sowas finde ich unschön und das sieht ziemlich ungewoht aus

Ich halt mich nur an das was Meyer in einem seiner Bücher mal geschrieben hat, ungefähr so: "Benutzerdefinierte Typen sollten sich so wie eingebaute verhalten".

Und da dies bei int's und Konsorten auch nicht funktioniert, tue ich dies für meine Typen auch, schue hats eingentlich auf den Punkt gebracht.

Aber jedem seine Entscheidung ...

Ich habe ja auch nicht gesagt, dass das, was camper geschrieben hat, falsch ist. Das Beispiel widerstrebt nur dem Design von C++, also dem statischen Typsystem und der daraus resultierenden statischen Fehlerbehandlung. Und auf der Basis, also wo Laufzeitbindung eine Rolle spielt, kann man eben keinen Memberzugriff auf Objektebene spezifizieren. Alles was bleibt, ist der Sichtbarkeitsbereich. Und dort spielt die Laufzeitbindung dann keine Rolle mehr.

Ich versteh dich grade überhaupt nicht.

Camper hat gesagt, wenn man die Sichtbarkeit auf Objektebene regeln könnte, dann kann man erst zur Laufzeit entscheiden ob ein Member sichtbar ist oder nicht. Du hast gesagt das braucht man nicht, da r nicht this ist und somit die Sichtbarkeit zur Compilerzeit entschieden werden kann.

Aber r ist doch this. Ob eine Variable jetzt r oder this heißt ist doch egal, hauptsache sie zeigen beide auf den selben Speicherbereich und sind vom selben Typ.

Also müsstest du fordern das this eine spezielle Variable ist, die einzigartig ist.

int select_foo(const Foo& foo1, const Foo& foo2)
{
    const Foo& r = rand() % 2 ? foo1 : foo2; 
    return r.foo_;
}

Wie willst du jetzt die Sichtbarkeit entscheiden?
Edit: select_foo ist friend-Funktion der Klasse Foo.

Camper hat gesagt, wenn man die Sichtbarkeit auf Objektebene regeln könnte, dann kann man erst zur Laufzeit entscheiden ob ein Member sichtbar ist oder nicht. Du hast gesagt das braucht man nicht, da r nicht this ist und somit die Sichtbarkeit zur Compilerzeit entschieden werden kann.

Nein, hier bringst du was durcheinander. camper brachte ein Beispiel, was zeigt, wie man Zugriff auf Objektebene unter C++ nicht realisieren kann. Mein Punkt war lediglich der, dass dies unter C++ sowieso nicht zur Debatte steht, weil es nicht zum Konzept von C++ passt. Das einzige was man unter C++ machen kann, ist, den Zugriff auf Objektebene über den Sichtbarkeitsbereich zu regeln, anstatt sich auf Objektidentität zu versteifen.