[C++] überlanden von operator==()

[Steffan (Gast)]

Ich möchte mir eine Art intelligenter Pointer schreiben.

Wenn ich für eine Klasse den Operator == überlade, kann ich in einer 
If-Abfrage ja

if ( myPointer == 0 )

schreiben.

Wenn ich jetzt aber nur

if ( myPointer )

schreibe, wird dann implizit operator==(0) aufgerufen?


Das soll also das Äquivalent zur Prüfung auf einen NULL-Pointer werden.

[Εrnst B. (ernst)]

nein, dann wird der "operator bool()" aufgerufen, der ist aber wohl auch 
trivial zu überladen.

[Steffan (Gast)]

ok, danke, ja der lässt sich natürlich auch leicht überladen.

[Bartli (Gast)]

> Ich möchte mir eine Art intelligenter Pointer schreiben.

Was soll der den können, rein aus Interesse?

[Andreas K. (a-k)]

Beispielsweise automatische Freigabe über reference count.

[Bartli (Gast)]

Naja, was man beispielsweise mit einem Smartpointer machen kann, ist 
mir auch klar, aber wenn ich jetzt einen refcounted Pointer will, 
schreib ich den nicht unbedingt selber, sondern schau mir mal 
boost::shared_ptr bzw. tr1::shared_ptr an. Dann seh ich auch, dass die 
Tücke im Detail steckt.

Deshalb meine Frage: was soll das Dingens können, was verfügbare 
Smartpointer nicht können?

[Steffan (Gast)]

Ich glaub, so einen Pointer denn ich benutzen will gibt es noch nicht ;)

Das ganze is Teil eines Spiels. Der Pointer soll auf eine Einheit auf 
einem bestimmten Kartenfeld zeigen. Über ++ und -- kann man dann nach 
bestimmten Kriterien über alle Einheiten auf dem Kartenfeld iterieren, 
da auf einem Feld mehreres existieren kann. z. B. ein Flugzeug, ein 
Fahrzeug und eine Straße.

[Εrnst B. (ernst)]

Ah. So ein Konstrukt nennt man dann üblicherweise "Iterator", und nicht 
Pointer.

also in etwa sowas soll nachher gehen?

for (SpielfeldTyp::const_iterator it=meinSpielfeld.begin(); it != meinSpielfeld.end(); ++it) {
  it->do_something().
}
std::sort(meinSpielfeld.begin(),meinSpielfeld.end());
std::copy(meinSpielfeld.begin(),meinSpielfeld.end(),std::back_inserter(meinVector));

usw?

[Bartli (Gast)]

Ja, halt sozusagen mit Filter.
Btw: Aus Sicht der stl-Algorithmen sind Pointer und Iteratoren dasselbe.

[Chris (Gast)]

> nein, dann wird der "operator bool()" aufgerufen, der ist aber wohl auch
> trivial zu überladen.

Schön wär es, wenn C++ so einfach wäre. :-)

In dem Fall if(x) wird x in einen bool-Kontext konvertiert. Das kann 
mittels operator bool geschehen, muss es aber nicht. Es stellt sich 
sogar heraus, dass operator bool() zu überladen meistens keine so gute 
Idee ist, weil man das Objekt x dann in jedem Kontext implizit in einen 
bool konvertieren kann. Sowas wird dann zum Beispiel möglich:
int i = x;

Zuerst wird x implizit nach bool konvertiert, was dann implizit als int 
gedeutet wird. Dass das hier Blödsinn ist, ist dem C++-Compiler egal.

Die übliche, einfache Methode ist daher anstelle operator bool den 
operator void* zu überladen. Anstelle false gibt dieser operator 0 
zurück und anstelle true zum Beispiel den this-Zeiger. Dann funktioniert 
if(x) immer noch wie gewünscht, aber int i = x nicht mehr.

Damit geht man wenigstens den häufigsten Fallen aus dem Weg. Die 
void*-Methode hat allerdings immer noch (zum Teil recht subtile) 
Nachteile, weswegen kompliziertere Methoden existieren, wie zum Beispiel 
operator Foo* zu überladen, wobei Foo ein "versteckter" Typ ist (etwa 
eine innere Klasse im private-Teil der äußeren).

[Steffan (Gast)]

Ich hab mittlerweile die Klasse implementiert. Mir is aufgefallen, dass 
es auch ohne Implementierung des Operators bool nicht zu einer undefined 
referenz kommt.

Ich hab zwar kein operator void* definiert, aber dafür operator 
cVehicle*, um den Iterator wieder in einen normalen Pointer casten zu 
können. Offenbar reicht dieser Operator aus, um die IF-Abfragen wie 
gewünscht verwenden zu können. Wie von Chris beschrieben, scheint dann 
zuerst implizit nach cVehicle* gecastet und der Pointer dann ganz normal 
als bool interpretiert zu werden.

Find ich jetzt persönlich etwas abenteuerlich, wie der Compiler sich 
hier was zurecht sucht, was passen könnte, aber solange die casts 
vernünftig definiert sind, sollte es ja keine Probleme geben.