Warum gibt es keinen Standard-Vergleichsoperator?

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.

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.

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.

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.

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.

Ä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?

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...

MaSTaH schrieb:

@Irgendwer: Lustig...

War ja auch nie wirklich ernst gemeint .