Kann mir jemand ein gutes Code-Beispiel für das Überschreiben des "="-operators geben? Ich habe eines auf www.cplusplus.com für den "+"-operator gefunden und es auf "=" übertragen, endet aber in einem Speicherfehler .

Wie sieht also ein Beispiel-Code für diesen override aus ?

Danke und greeetz
Kessi

class foo
{
public:
	foo &operator=( const foo &other )
	{
		if ( this != &other )
		{
			// mach irgendwas
		}

		return *this;
	}
};

Wenn du deinen Code noch zeigst könnte man evtl feststellen warum es zu einem Speicherfehler kommt.

grüße

CXmlTag CXmlTag::operator=(CXmlTag m_xtOriginal) {
   CXmlTag xtCopy("Test", "Test");
   xtCopy.set_strName(m_xtOriginal.get_strName());
   xtCopy.set_strValue(m_xtOriginal.get_strValue());
   xtCopy.set_xtParentTag(m_xtOriginal.get_xtParentTag());

   return xtCopy;
}

Warum muss ich denn mit diesem "&"-Operator arbeiten? Was soll der überhaupt? Ich kenne nur den "*", welcher definiert, dass z.B. mein Rückgabewert ein Pointer ist.

Und warum muss ich den Wert von this zurückgeben? Muss ich anstatt eines eigenen Objekts (xtCopy) this als Kopie anfertigen?

Thx und greeetz
Kessi

Warum muss ich denn mit diesem "&"-Operator arbeiten?

Weil du eine Referenz auf das Ziel-Objekt (this) zurückgeben solltest.

Was soll der überhaupt?

In dem Kontext ist es der Referenz-op.

Und warum muss ich den Wert von this zurückgeben?

Musst du nicht. macht man aber, dass man z.B.

a = b = c;

schreiben kann. Würde dein =op nämlich nichts zurückgeben, würde das nicht klappen.

Muss ich anstatt eines eigenen Objekts (xtCopy) this als Kopie anfertigen?

Nein. Du sollst die Daten auf die von m_xtOriginal setzen:

CXmlTag& CXmlTag::operator=(const CXmlTag &m_xtOriginal) {  //Hier nehmen wir ne konstante Referenz, d.h. Objekt wird nicht kopiert
   //Du kannst hier natürlich direkt auf den Daten arbeiten, aber da ich die Namen dieser nicht kenne, hab ich die Methoden benutzt...
   set_strName(m_xtOriginal.get_strName());
   set_strValue(m_xtOriginal.get_strValue());
   set_xtParentTag(m_xtOriginal.get_xtParentTag());

   return *this;
}

Das hier:

David_pb schrieb:

if ( this != &other )
        {
            // mach irgendwas
        }

kann man sich auch sparen, das kostet nur unnötig.

MfG

GPC

Den eigentlichen Teil hat GPC schon gut beantwortet (finde ich), deswegen von mir nur noch 2 Anmerkungen:

KessiMC schrieb:

...

CXmlTag CXmlTag::operator=(...

...

hier nutzt Du implizit den CopyCtor, um ein temporäres CXmlTag-Objekt zu erzeugen:
Der Aufrufer erhält nämlich nicht das lokale Objekt "xtCopy", sondern nur eine "temporöre Kopie" davon. Wenn Du nun im CopyCtor (evtl. wieder implizit) den operator=() verwendest, bekommst Du eine Endlosschleife und damit einen "Stackoverflow".

Allgemein: "Eine Referenz (&) ist ein 'verpflichtender Pointer' "
Sie kann also nicht auf 0 zeigen und wenn man kann nicht mehr ändern, worauf sie zeigt. Deswegen gibt es auch kein explizites "Dereferenzieren" wie bei einem Pointer, sondern man arbeitet mit ihr so, wie mit "einem Objekt selbst" (also mit "." ).

Gruß,

Simon2.

Da hab' ich heut' ja noch richtig 'was gelernt Und der Speicherfehler erscheint auch nicht mehr .

Thx und greeeetz
Kessi

Das hier:

David_pb schrieb:

if ( this != &other )
        {
            // mach irgendwas
        }

kann man sich auch sparen, das kostet nur unnötig.

Sollte man wenigstens im Debugmodus testen, denn das hat mir schon unnötigen Ärger erspart

ASSERT(this != &other);

Simon2 schrieb:

Allgemein: "Eine Referenz (&) ist ein 'verpflichtender Pointer' "
Sie kann also nicht auf 0 zeigen und wenn man kann nicht mehr ändern, worauf sie zeigt.

int& i = *static_cast<int*>(0);

Er kann auf 0 zeigen, sollte er aber nicht. Ändern kann man Referenzen ebenfalls mit bösen Tricks und Speichereingriffen

GPC schrieb:

Das hier:

David_pb schrieb:

if ( this != &other )
        {
            // mach irgendwas
        }

kann man sich auch sparen, das kostet nur unnötig.

Sollte man wenigstens im Debugmodus testen, denn das hat mir schon unnötigen Ärger erspart

ASSERT(this != &other);

Na ja, zum eimaligen Testen von Selbstzuweisungen vielleicht, aber ansonsten nein. Ein sauber geschriebener =op verkraftet den seltenen Fall, dass mal eine Selbstzuweisung kommt. Wenn man so viele davon hat, dass die Performance leidet, stimmt was am Programm grundsätzlich nicht.

MfG

GPC

...

int& i = *static_cast<int*>(0);

...

Das war mir sehr wohl bewusst, aber dass man in C++ jedes Bedeutung eines Konstrukts umgehen/mißbrauchen kann, ist weder etwas Neues, noch ändert es etwas an der der Bedeutung.

Oder würdest Du "private" nicht mehr als "Zugriffsschutz" bezeichnen, weil man es ebenfalls umgehen kann ?

Einfaches Gegenbeispiel: Wie würdest Du Dich denn gegen das von Dir skizzierte Verhalten absichern ? :p
Dass es bei einem Pointer eine "=="-Abfrage gibt, drückt seine "Optionalität" aus ... dass es bei Referenzen das gerade nicht gibt, das Gegenteil.

Gruß,

Simon2.

ASSERT(this != &other);

Was ist an a=a falsch?

a = besseresDerBeidenObjekte(a,b);

Bei komplizierten Objekten wäre es schön das per Referenz machen zu können. Da wäre so ein ASSERT absolut fehl am Platze. Selbstzuweisung sollte korrekt gehandhabt werden. Ob es sich aber lohnt es zu optimieren... am einfachsten man implentiert copy&swap und schaut später, ob man was schnelleres braucht.

Grundsätzlich gilt: wann immer man einen op= implementiert, sollte man auch den Fall Selbstzuweisung im Kopf haben, denn ein a = a ist, wie Jester bereits bemerkte, kein Fehler sondern allenfalls eine Seltenheit.
Fast noch wichtiger ist aber, dass man die Exception-Sicherheit berücksichtigt: wann immer möglich sollte der op= die strong guarantee erfüllen, also entweder der op= läuft komplett ab, oder aber das Originalobjekt bleibt unverändert.

Die Gefahr bei der Selbstzuweisung ist, dass man sich erst das eigene Objekt unterm Hintern weg zerstört und dann versucht von dem nunmehr zerstörten Objekt eine Kopie zu machen. Klassisches Beispiel:

// KATASTROPHE bei a = a;
String& String::operator=(const String& other) {
  delete [] buffer_;
  buffer_ = new char[other.size_]; 
  copy(buffer_, other.buffer_, other.size_);
  ...
  return *this;
}

Dieses Problem kann man mit dem Test auf this != &other lösen:

// Erlaubt auch a = a;
String& String::operator=(const String& other) {
  if (this != &other) {
    delete [] buffer_;
    buffer_ = new char[other.size_]; 
    copy(buffer_, other.buffer_, other.size_);
    ...
  }
  return *this;  
}

Diese Version ist aber leider nicht Exception-sicher. Sollte z.B. die Allokation fehlschlagen, dann besitzt *this einen undefinierten Wert.

Dieses Problem wiederum löst man, indem man erst alle "gefährlichen" Operationen
auf einer Kopie durchführt und danach die Kopie und *this mit "ungefährlichen" Operationen vertauscht:

String& String::operator=(const String& other) {
  if (this != &other) {
    // alles was "throwen" kann zuerst.
    char* temp = new char[other.size_];
    // dann vertauschen mit sicheren Operationen
    std::swap(temp_, buffer_);
    copy(temp, other.buffer_, other.size_);
    ...

    delete [] temp;
  }
  return *this;  
}

Das Interessante: diese Version würde auch ohne Test auf Selbstzuweisung selbige korrekt behandeln. In diesem Fall wird zwar unnötigerweise kopiert, korrekt bleibt das Ergebnis aber.

String& String::operator=(const String& other) {
  // alles was "throwen" kann zuerst.
  char* temp = new char[other.size_];
  // dann vertauschen mit sicheren Operationen
  std::swap(temp_, buffer_);
  copy(temp, other.buffer_, other.size_);
  ...
  delete [] temp;
  return *this;  
}

All dies kann man veralgemeinern: der Test auf Selbstzuweisung (this != &other) hilft zwar gut gegegen das "Objekt-unter-Hintern-weg-gelöscht"-Phänomen, für die Exception-Sicherheit ist er allerdings nicht ausreichend. Genauer: ein op=, der auf den Test this != &other *angewiesen* ist, ist niemals Exception-sicher.

Um Exception-sicher zu sein, muss ein Operator= erst alle Operationen die eine Exception werfen könnten auf einer Kopie durchführen und dann Kopie und Original mit Operationen vertauschen, die keine Exceptions werfen können.

Zur Erinnerung: die kanonische Form des op=, und damit das von Jester angesprochene Copy&Swap-Idiom, die sowohl Selbstzuweisung korrekt behandelt als auch Exception-sicher ist, sieht so aus:

Class& Class::operator=(const Class& other) {
   Class temp(other);
   Swap(temp);  // vertauscht den Zustand von *this und temp unter 
                // Verwendung von non-throwing-Operationen
   return *this;
}

Neku schrieb:

...

int& i = *static_cast<int*>(0);

...

Oder würdest Du "private" nicht mehr als "Zugriffsschutz" bezeichnen, weil man es ebenfalls umgehen kann ?

Einfaches Gegenbeispiel: Wie würdest Du Dich denn gegen das von Dir skizzierte Verhalten absichern ? :p

'private' sehe ich lediglich als Hilfe, nicht als Schutz.

Gegen das obige Verhalten würde ich gar nichts tun. Wenn ich mit Referenzen arbeite, dann heißt das für mich, dass der Erzeuger der Referenz für die Gültigkeit sorgen muss. Mir ging es nur darum, dass eine Referenz auf 0 zeigen kann (aber nicht im Sinne von 'darf' - undefiniertes Verhalten ;))

Jester schrieb:

Neku schrieb:

ASSERT(this != &other);

Was ist an a=a falsch?

Es ist nicht falsch. Es wird nur darauf hingeweisen wenn der Fall eintritt.
Ich habe schon mehrfach das Problem gehabt, dass ein Bug irgendwo im Programmlauf aufgetreten ist, der (wie ich erst nach mehreren Stunden Arbeit herausgefunden habe) lediglich auf eine versehentliche Selbstzuweisung zurückzuführen war. Ich habe mir daher angewöhnt, bei den meisten Zuweisungsoperatorüberladungen solch ein Assert einzubauen. Bei einer versehentlichen Selbstzuweisug werde ich gewarnt, bei einer absichtlichen und erlaubten kann ich die Warnung entfernen.