virtual operator == , wie den vergleich durchführen?

knivil

@antwort:
Wenn einmal virtual immer virtual, dann sollte man es aber auch ueberall hinschreiben ...

volkard

knivil schrieb:

@antwort:
Wenn einmal virtual immer virtual, dann sollte man es aber auch ueberall hinschreiben ...

nee.

knivil

Hmm, ich muss da mal nachschlagen ... Meine Frage: Ist

bool operator == (const base &);

in Klasse a im Beispiel von antwort virtual? Denke schon.

Edit: Habe es grad ausprobiert. Sie ist virtuell.

Shade Of Mine

knivil schrieb:

Hmm, ich muss da mal nachschlagen ... Meine Frage: Ist
bool operator == (const base &);
in Klasse a im Beispiel von antwort virtual? Denke schon.

Edit: Habe es grad ausprobiert. Sie ist virtuell.

das lustige dabei ist dadurch sowas:

struct Virtual {
  virtual void foo() = 0;
};

struct NonVirtual {
};

template<tyoename Polciy>
class Class : public Policy {
public:
  void foo() {}
};

Und dann eben
Class<Virtual> oder Class<NonVirtual> um laufzeit polymorphie zu aktivieren oder deaktivieren

knivil

Zaehlt das schon zu Code Obfuscation?

pumuckl

volkard schrieb:

A const& otherA = dynamic_cast<A const&>(other);
hier wäre static_cast ok, oder?

In dem Fall ja, weil die Verwendung von typeid() das schon sichergestellt hat dass es der richtige Typ ist. Die Verwendung von dynamic_cast würde nochmal den ganzen RTTI-Apparat in Gang setzen.

Ich wäre mit einem polymorphen op== auch sehr vorsichtig, da man nicht garantieren kann dass der von jeder abgeleiteten Klasse richtig und symmetrisch ausgeführt wird. Beispiel: Klasse A verlangt, dass beide operanden vom Typ A sein sollen, Klasse B dagegen verlangt nur, dass die Base-Komponenten gleich sein sollen. Damit kann b==a true ergeben, während a==b false ergibt. Ich würd daher auch eine methode "equals" im Java-Stil vorziehen, wenn überhaupt ein Vergleich mit polymorphem Verhalten sinnvoll ist.

volkard schrieb:

knivil schrieb:

@antwort:
Wenn einmal virtual immer virtual, dann sollte man es aber auch ueberall hinschreiben ...

nee.

Doch im Normalfall schon. Allein schon der Dokumentation wegen dass es beabsichtigt ist die virtuelle Methode von 12 Klassen weiter oben in der Hierarchie zu überschreiben, und dass ein Client auch weiß dass sich die Methode virtuell verhält. Shades template ist natürlich ne Ausnahme.

RHBaum

virtual bool operator == (const base &) = 0;

soweit ich weiss, ist das ned standardisiert.
Also die compiler machen hier was sie wollen. kann sein das sie nen Compiler oder Linker fehler bringen, oder das ding wirklich virtuell machen ...

Ciao ...

pumuckl

RHBaum schrieb:

virtual bool operator == (const base &) = 0;

soweit ich weiss, ist das ned standardisiert.

Warum sollte es das nicht sein? operator== ist in dem Fall ne Memberfunktion wie jede andere auch, kann also auch genauso gut virtuell sein.

Shade Of Mine

knivil schrieb:

Zaehlt das schon zu Code Obfuscation?

Es zählt zu den Tricks die man kennen sollte.

Ich schreib übrigens nie virtual hin wenn ich nicht muss. da virtual imho sowieso nichtssagend ist. ein override/new/virtual wie in C# würde ich praktisch finden aber virtual alleine sagt nix aus. ist es virtual weil eine funktion einer basisklasse neu definiert wurde, oder wurde eine überschrieben? oder will man nur eine erweitertes interface anbieten, etc.

knivil

Ich schreibe es immer hin, damit jemand weiss, ob wie und was beim Ueberladen passiert, ob es einen vtable-lookup zusaetzlich kostet (billig bei Einfachvererbung, teurer bei Mehrfachvererbung) etc. ... Da finde ich es bloed in den Basisklassen nachzusehen. Meine Devise: alle Informationen einfach zugaenglich. Naja, uebertreiben sollte man es dann wieder nicht.

Wobei sich mir grade der Sinn eines virtuellen Vergleichsoperators nicht erschliesst, da ja ein abgeleitetes Objekt immer irgendwie anders ist als ein Basisobjekt.

hustbaer

@volkard & pumuckl:

pumuckl schrieb:

volkard schrieb:
A const& otherA = dynamic_cast<A const&>(other);
hier wäre static_cast ok, oder?
In dem Fall ja, weil die Verwendung von typeid() das schon sichergestellt hat dass es der richtige Typ ist. Die Verwendung von dynamic_cast würde nochmal den ganzen RTTI-Apparat in Gang setzen.

Jopp, türlich ist static_cast hier ausreichend. Ich dachte mir bloss bevor mich wer deswegen anpflaumt schreib ich gleich dynamic_cast
Persönlich würde ich auch eher static_cast schreiben. Gerade weil dynamic_cast auf "meinem" Compiler (MSVC) so lahm ist.

Beispiel: Klasse A verlangt, dass beide operanden vom Typ A sein sollen, Klasse B dagegen verlangt nur, dass die Base-Komponenten gleich sein sollen.

Jo. Meine Lösung ist auch nur brauchbar im einfachen Fall, wo alle verlangen dass die Typen exakt gleich ist. Alles andere halte ich auch für "asking for trouble".

volkard

hustbaer schrieb:

Ich dachte mir bloss bevor mich wer deswegen anpflaumt schreib ich gleich dynamic_cast

wir werden grundsätzlich angepflaumt und tun das auch gegenseitig. :p

hustbaer

volkard schrieb:

hustbaer schrieb:

Ich dachte mir bloss bevor mich wer deswegen anpflaumt schreib ich gleich dynamic_cast

wir werden grundsätzlich angepflaumt und tun das auch gegenseitig. :p

*zurück-pflaum*
:p