Ich habe z.B. folgende Klasse:

class Foo
{
  private:
    int D;
  public:
    const int& Data() const{return D;}
    int& Data(){return D;}
};

Soweit, so gut. Nun habe ich eine Bibliothek, die in C geschrieben wurde. Diese hat eine Funktion, welche ein int erfordert. Nun schreibe ich eine Funktion, die ein beliebiges Foo -Objekt zum aktuellen Objekt macht:

void MakeCurrent(const Foo& Object)
{
  CLib_GimmeSomeInt(Foo.Data()); //Funktionssignatur: void CLib_GimmeSomeInt(int)
}

Nun mein Problem: Wenn ein User kommt, eine Instanz von Foo erzeugt, MakeCurrent mit dieser Instanz aufruft und nach dem Aufruf die Instanz ändert, denkt er doch sicher, dass sich die Änderung der Instanz auch auf die C-Bibliothek ausgewirkt hat. Dem ist aber nicht so, da die C-Bibliothek eine Kopie für sich selbst angefertigt hat.

Lösungen:
GetData und SetData machen (finde ich extrem hässlich)
Im regelmäsigem Interval MakeCurrent automatisch mit dem letzten Parameter aufrufen (ist ja 'n Witz)
Irgendwie Wrappen (hässlich und im konkreten Fall habe ich mehrere Datentypen)
Irgend eine Lösung auf die ich noch nicht gekommen bin

MfG, EOutOfResources

Ansonsten solltest du dir sinnvolle Kapselung überlegen, Referenzen auf veränderliche Objekte zurückzugeben ist oft fragwürdig. Warum ist D nicht gleich öffentlich?

Statt int& ein Proxy zurückgeben, dessen operator= die C-Bibliothek synchron hält.

Der Zuweisungsoperator ist ja nicht der Einzige, der den Wert verändern kann.

Nexus schrieb:

Warum ist D nicht gleich öffentlich?

Im konkreten Fall hat die Klasse noch Methoden, die das Ganze verändern. Aber ich könnte aus der Klasse ein POD machen und die Methoden zu freien Funktionen machen.

EDIT: Ich könnte den User einfach mit der Aufgabe, selbst upzudaten, zurücklassen.

Der Zuweisungsoperator ist ja nicht der Einzige, der den Wert verändern kann.

Nein, aber er wird dafür am häufigsten verwendet. Du kannst ja auch noch andere Operatoren überladen, wenn sich der Wert eher wie ein int verhalten soll. Ganz hinkriegen wirst du die Ähnlichkeit aber nicht.

EOutOfResources schrieb:

EDIT: Ich könnte den User einfach mit der Aufgabe, selbst upzudaten, zurücklassen.

Und diese Benutzerunfreundlichkeit wofür? Weil du den Zugriff auf D nicht ordentlich kapseln willst?

Der Fall, in dem bei der Änderung einer Objekt-Eigenschaft automatisch noch etwas Zusätzliches getan werden muss, ist ein Paradebeispiel für die Notwendigkeit einer Set-Funktion.