Warum gibt es keinen Standard-Vergleichsoperator?

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

[Irgendwer]

MaSTaH schrieb:

@Irgendwer: Lustig...

War ja auch nie wirklich ernst gemeint .

[otze]

ich geb nur ein stichwort: exception safety.

ein standard op= ist nicht exception safe zu machen, hier ein beispiel:

class foo{
        int i;
        std::vector<bar> j;
    public:   
};

gäbs hier nen standard op= würd er wahrscheinlich so aussehen:

foo& operator=(const foo& Operand){
    i=Operand.i;
    j=Operand.j;
}

sieht ja auf dem ersten blick nich so schlimm aus oder?
jetzt nehmen wir mal an, j wirft ne exception, weil der vector bei einer anstehenden erweiterung nichmehr genug platz allokieren kann(also new schlägt fehl).
die exception geht an den benutzer raus,egal was der benutzer jetzt macht, der alte wert von i ist übrschrieben, und der alte wert von j wurde gelöscht.
selbst wenn der vector exception sicher ist(was er ist), i bricht uns das genick, die klasse befindet sich in einem undefinierten zustand.

[peterchen]

@otze: gutes Argument!
Du kannst die betroffenen Daten aber in eine Basisklasse oder einen Member packen, und einen exception-sicheren operator= drumlegen. Ist zwar nicht immer eine Lösung, aber wenn man ein dutzend member hat...

@Optimizer:
Ich hatte bisher genügend Fälle, in denen bestimmte Operationen auf jeden member angewandt werden sollen. Wenn dir nicht gefällt das die "automatisch" da sind, kann ich das verstehen - aber gar nicht??? Vielleicht gefällt es Dir ja so besser:

// nicht ganz echtes cpp
class foo
{
  // ... schön viele Member
  foo(foo const & rhs) memberwise;
  // operator= nicht definiert, also gibt es den nicht
};

oder noch hübscherer:

// nicht ganz echtes cpp
class foo
{
  // ... schön viele Member
  foo & operator=(foo const & rhs)
  {
    try 
    {
      memberwise.operator=(rhs)
    }
    catch (...)
    {
      // now what to do? 
    }
  }
};

@Mastah: braucht man nicht mal macros dazu, geht mit entsprechenden membern bzw. basisklassen genauso:

class nocopy
{
  private:
    nocopy(nocopy const & rhs);
    nocopy & operator=(nocopy const & rhs);
};

class CMyClass : public nocopy
{
   // oder auch: nocopy you_cannot_copyme;  
   // ... alles weitere
};

[otze]

peterchen schrieb:

@otze: gutes Argument!
Du kannst die betroffenen Daten aber in eine Basisklasse oder einen Member packen, und einen exception-sicheren operator= drumlegen. Ist zwar nicht immer eine Lösung, aber wenn man ein dutzend member hat...

sicher kann man sonen op machen:

foo& operator=(foo Operand){
    std::swap(*this,temp);
}

aber das wäre bei simpel klassen von der performance her absolute verschwendung...