Warum gibt es keinen Standard-Vergleichsoperator?

[peterchen]

bestimmte Regeln gelten ja immer noch (auch wenn sie von der Sprache nicht erzwungen werden) - z.B. das operator!= das Gegenteil von operator== zurückliefert. und das - sofern ein Vergleichsoperator sinnvoll - (a=b, a==b) true zurückliefert.

Ich sehe technisch keinen Unterschied zwischen einem Default-Zuweisungs- und Vergleichsoperator. Für beide ist ein die member-für-member - Operation sinnvoll, bei beiden gibt es den Fall, daß die default-Implementation nicht erstellt werden kann.

Der einzige Unterschied, den ich sehe, ist, daß ein operator== seltener benötigt wird, aber das erscheint mir als Grund ein bißchen schwach.

[Gast]

Stell dir ne Klasse für Brüche mit Zähler und Nenner vor.
Der Standard-operator= macht Sinn.

Der Standard-operator== liefert für 4/8 == 2/4 false.

Naja, ich finde weder einenn Standard-== noch einen Standard-= sinnvoll, aber das ist ein anderes Thema...

[Shade Of Mine]

Der op= und der CopyCtor müssen wegen der kompatibiltät zu C drinnen sein. Einen op== braucht man für C kompatibilität jedoch nicht.

[typecast]

Shade Of Mine schrieb:

Der op= und der CopyCtor müssen wegen der kompatibiltät zu C drinnen sein. Einen op== braucht man für C kompatibilität jedoch nicht.

CopyConstruktor in C?
Ich wusste nicht, dass es in C sowas gibt. Bei structs vielleicht?!?!? *verwirrtist*

@peterchen: Der operator= arbeitet auch nicht komponentenweise, sondern er kopiert einfach Byte fuer Byte (der Compiler ist da nicht intelligent genug um zu schauen, was kopiert werden sollte)
Glaubst du sowas wuerde bei einem == operator sinn machen?
Stell dir folgendes vor:

class foo {
public: 
   int *bar;
};

Jetzt werden bar unterschiedliche grosse Felder zugewiesen. Was soll der operator== oder der operator!= machen?

[Shlo]

typecast schrieb:

Der operator= arbeitet auch nicht komponentenweise, sondern er kopiert einfach Byte fuer Byte

Seit wann? op= kopiert die einzelen Elemente ebenfalls per Zuweisung . Bei Builtins kann ich mir das noch vorstellen...

[Shade Of Mine]

typecast schrieb:

CopyConstruktor in C?

Natürlich nicht.

Aber
int a=b;
bedeutet Aufruf des Coypctors in C++

in C natürlich nicht, aber man kann ja nicht einmal nen copyctor aufrufen und einmal nicht, je nachdem wie man lustig ist...

deshalb braucht man in C++ einen automatischen copyctor um zu C kompatibel zu bleiben.

[typecast]

@Shade Of Mine: Ok

@rest: Ich ziehe meine Behauptung ein Object wuerde byte fuer byte kopiert wieder zurueck.
Ich habe mir eben sagen lassen, dass doch auf jedes einzelne Element sein operator= ausgefuehrt wird

[peterchen]

@Optimizer, SoM u.a.: Gibt genauso genügend Fälle, wo der Default-op= sinnlos ist. Die Argumente lassen sich alle auch auf einen operator== anwenden.

Ist halt so (und "nur" ärgerlich, wenn man structs mit ein paar Dutzend Membern vergleichen muß), ich kann mir nur nicht vorstellen, das Bjarne einfach nicht dran gedacht hat

[SideWinder]

@peterchen: Eventuell funktioniert da irgendein fauler Trick: Mit this hast du schonmal die Adresse deiner Klasse. Wenn du Glück hast (einfach mal ausprobieren) sind die nächsten X Bytes die Eigenschaften (Einfach mit sizeof() mal probieren). Dann müsstest du nur noch einen Speicherbereich mit dem Anderen vergleichen?!

Keine Garantie

MfG SideWinder

[peterchen]

@SideWinder: leider nicht

erstens will ich für member mit überladenem operator== auch diesen ausführen, keinen bitweisen vergleich.
zweitens darf C/C++ pad bytes zwischen den membern einführen (und macht das auch fleißig, um Daten an "gerade" Adressen zu bekommen), deren Wert undefiniert ist.

[Irgendwer]

erstens will ich für member mit überladenem operator== auch diesen ausführen, keinen bitweisen vergleich.
zweitens darf C/C++ pad bytes zwischen den membern einführen (und macht das auch fleißig, um Daten an "gerade" Adressen zu bekommen), deren Wert undefiniert ist.

Das Problem mit den Padbytes ist leicht gelöst einfach ein

memset(this,0,sizeof(*this));

an den Anfang des Ctors.

[Gast]

peterchen schrieb:

@Optimizer, SoM u.a.: Gibt genauso genügend Fälle, wo der Default-op= sinnlos ist. Die Argumente lassen sich alle auch auf einen operator== anwenden.

Ist halt so (und "nur" ärgerlich, wenn man structs mit ein paar Dutzend Membern vergleichen muß), ich kann mir nur nicht vorstellen, das Bjarne einfach nicht dran gedacht hat

Klar. Wie gesagt, ich finde eigentlich überhaupt keinen standardmäßig erzeugten Operator sinnvoll.

[Walli]

Warum nicht? So kann man sich bei PODs einiges an redundantem Code sparen.

[Gast]

Sowas saugt z.B.:

private:
	// Verboten!
	Object(const Object&);
	// Verboten!
	const Object& operator=(const Object&);

Jetzt hat man sogar noch nicht mal die Garantie, dass nicht doch die Operatoren genutzt werden, erst der Linker weint ganz sicher dann.

Man sollte es zumindest abstellen können.

[Gast]

Ich will halt ganz einfach manchmal (meistens!) nicht, dass es diesen Operator und Copy-Konstruktor gibt und ich möchte verdammt nochmal das Recht haben, das selber zu entscheiden.
Das ist echt ne krasse Einmischung in meine Kompetenzen.

[peterchen]

@Irgendwer:
das memset geht schief, sobald du eine einzige virtuelle methode drin hast

@Optimizer:
Mich stört auch der Mehraufwand, die "standards" abzuschalten. Man hat sich wahrscheinlich für die Variante entschieden, die ohne zusätzliche keywords auskommt.

Die Möglichkeit, Member-weise operationen zu definieren ist aber schon hübsch, oder?

[Walli]

@Optimizer: Wenns dich stört, dann schreibe dir doch ein Makro, welches dir private Dummy-Opertoren da rein bastelt oder so.

[Gast]

Ähm, dann hab ich einen 1- statt 2- Zeiler. Wow.

Die Möglichkeit, Member-weise operationen zu definieren ist aber schon hübsch, oder?

Ähm was meinst du jetzt genau?

[Irgendwer]

peterchen schrieb:

@Irgendwer:
das memset geht schief, sobald du eine einzige virtuelle methode drin hast

Dann halt einfach in den operator new oder die ersten 4 Bytes auslassen.

[Walli]

@Irgendwer: Lustig...