Spezielles Problem: Zeiger versus Referenz.

Kuggug!
Ich habe eine Klasse Rect und eine Klasse Canvas, die von Rect erbt.
Canvas canvas;
Nu wollte ich eine Referenz in einem Vector speichern:

vector <Rect&> vRect;
vRect.push_back(&canvas);

Das gibt gleich nen polymorphen Fehler:

error C2529: 'reference': Verweis auf Verweis ungültig
error C2528: 'const_pointer': Zeiger auf Verweis ungültig
error C2535: 'Rect &(*std::allocator<_Ty>::address(Rect &(&)) const)': Memberfunktion bereits definiert oder deklariert
error C2664: 'std::vector<_Ty>::push_back': Konvertierung des Parameters 1 von 'Canvas *' in 'Rect &(&)' nicht möglich

So gehts auch nicht, ergibt ebenfalls ne multiple Fehlermeldung:

vRect.push_back(canvas);

Mit Zeigern gibt es da keine Probleme:

vector <Rect*> vRect;
		vRect.push_back(&canvas);

Seitens der Sprache C bin ich sehr gut mit Zeigern vertraut, mit Referenzen habe ich es offensichtlich nicht so. Sollte ich lieber - nach dem Motto: Schuster, bleib bei deinem Leisten - bei Zeigern bleiben?
Oder geht das in diesem Fall mit Referenzen nicht?

TyRoXx

Kurze Antwort: Sowas geht mit Referenzen nicht, da diese sofort initialisiert werden müssen und danach nicht geändert werden können.

Nexus

Wenn du die Flexibilität brauchst, sind Zeiger geeigneter. Die kannst du wild rumschubsen, Arithmetik damit machen, dereferenzieren... Im Rahmen der Vernunft natürlich.

Zeiger innerhalb von STL-Containern, die selbst Speicher besitzen, sind etwas gefährlich. Wenn man nicht wahnsinnig aufpasst, hat man besonders bei komplexeren Operationen sehr schnell Memory Leaks, Dangling Pointers und die üblichen Probleme. Von daher: Wenn du Boost hast, ist sind die Pointer-Container ein guter Ansatz. Da werden die Zeiger automatisch freigegeben und alles läuft viel sicherer ab. Ansonsten gäbs auch noch Smart-Pointer wie shared_ptr , welche sich ihren Besitz teilen. Allerdings haben die einen kleinen Overhead durch die Referenzzählung, der eigentlich unnötig ist und manchmal hinderlich sein kann.

Mir ist gerade aufgefallen, das nicht einmal die Deklaration gültig ist:

vector <Rect&> ref;

Nagut, geht nicht.
THX!

Th69

Außerdem solltest du dir überlegen, ob ein Canvas wirklich ein Rect ist, d.h. ob hier Ableitung überhaupt richtig ist (ein Canvas wird ja wohl noch über mehr Eigenschaften verfügen).
Besser wäre es Rect als Member zu definieren.

Th69 schrieb:

Außerdem solltest du dir überlegen, ob ein Canvas wirklich ein Rect ist, d.h. ob hier Ableitung überhaupt richtig ist (ein Canvas wird ja wohl noch über mehr Eigenschaften verfügen).
Besser wäre es Rect als Member zu definieren.

Ojaaah! Das ist ein Rect wie es im Buche steht. Ein sowas von Rect aber auch!
MfG.