Joachim B. schrieb:
> Karl Heinz schrieb:
>> Ein
>> public:
>> .....
>> müsste es eigentlich auch tun.
>
> danke, ich glaube ich verstehe so halb, aber da ich in cpp ganz schön
> absaufe
Im Prinzip ist das, worum es hier geht, sehr simpel.
Du bist von C gewohnt, dass ein
einfach nur eine Umkopieraktion ist.
Dagegen ist auch ncihts zu sagen.
In C++ ist da aber noch ein Schritt dazwischen. Eine derartige Zuweisung
ist im Sinne der Objektorientierung einfach nur ein AUfruf einer
Memberfunktion (die lediglich einen etwas spezielleren Namen hat).
D.h. das Objekt a ist selbst dafür zuständig, was bei einer Zuweisung zu
passieren hat. Es kapselt dieses Wissen in der Implementierung dieses
Operators (der nichts anderes als eine speziellere Form einer Member
Funktion ist).
Wenn du keine derartige Member Funktion selber schreibst, dann schreibt
der Compiler eine für dich. Die macht - tada - nichts anders als eine
Zuweisung aller Member des Objektes. Damit sind wir wieder genau da,
dass ein
für Klassen, die keine Spezialbehandlung benötigen, genau das macht, was
du erwarten würdest und was du auch gewohnt bist.
In deinem speziellen Fall, kommt dir das volatile von
in die Quere.
Denn der standardmässig erzeugte Operator ist dafür nicht ausgelegt. Der
ist eigentlich nur für nicht volatile Objekte gedacht. Warum das wichtig
ist, ist einer Eigenschaft geschuldet: Der Operator gibt eine Referenz
auf sein Objekt zurück. Und da darf dieses volatile nicht verloren
gehen. D.h. es bleibt nichts anderes übrig, als eine Version des
Operators zu schreiben, die ausdrückt: kann für volatile Objekte
aufgerufen werden
1 | ....
|
2 |
|
3 | ........ operator= ( ..... ) volatile;
|
und liefert dann auch wieder eine Referenz auf ein volatile Objekt
1 | ....
|
2 |
|
3 | volatile MyClass& operator= ( .... ) volatile;
|