Konstantes Objekt als Attribut

huhu ihrs,
hab mal wieder eine Frage:

Wieso muss man die operator= Funktion explizit implementieren,
wenn man ein konstantes Objekt als nicht-statisches Attribut hat?

Ich mein... wo ist hier die Logik ?
Bei einem konstanten Objekt ... da gibt es sowieso nichts zu kopieren^^

Und vor allem, wieso muss man den Copy Konstruktor dann nicht auch selber machen ?

danke schonmal für Antworten

SeppJ

edit: Oh, ich glaube ich habe dich falsch verstanden.

edit2: Jetzt die richtige Erklärung:

Angenommen du hast das:

struct A{
	const int a;
	A(int b):a(b){}
};

int main()
{
  A n(5);
  A m(6);
  m=n;
}

Welchen Wert soll m.a denn hinterher haben? 6? Dann habe ich bei der Zuweisung ja nichts verändert. 5? Dann habe ich eine konstante Variable geändert. Beide Möglichkeiten passen nicht richtig, deshalb kann der Compiler diese Entscheidung nicht übernehmen und fragt den Programmierer.

Hat man hingegen dies:

int main()
{
  A n(5);
  A m(n);
}

Dann ist ganz klar, dass m.n hinterher 5 sein soll und der Compiler kann den Defaultkonstruktor nehmen.

Nexus

Dweb schrieb:

Wieso muss man die operator= Funktion explizit implementieren,
wenn man ein konstantes Objekt als nicht-statisches Attribut hat?

Weil der default-generierte Zuweisungsoperator memberweise kopiert und konstanten Objekten per Definition nichts zugewiesen werden kann.

Wenn du den Zuweisungsoperator selbst implementieren musst (womöglich mittels üblen Hacks), nur um das Verhalten des compilergenerierten bei const -Membern nachzubilden, solltest du dir überlegen, ob das const wirklich sinnvoll ist.

Dweb schrieb:

Ich mein... wo ist hier die Logik ?
Bei einem konstanten Objekt ... da gibt es sowieso nichts zu kopieren^^

Wieso sollte ein konstantes Objekt nicht kopierbar (durch den Kopierkonstruktor) sein? Um eine Kopie zu erstellen, muss das Original im Normalfall nicht verändert werden.

Also SeppJ,

wenn ich dich dein Beispiel nun richtig verstanden habe,
dann soll der Compiler ja einerseits eine Zuweisung durchführen (m=n),
andererseits darf er das aber nicht, da das Attribut (a) konstant ist.

Und aufgrund dieses Konfliktes muss dies der Programmiere handhaben.
richtig so ?^^

Nexus schrieb:

Wieso sollte ein konstantes Objekt nicht kopierbar (durch den Kopierkonstruktor) sein? Um eine Kopie zu erstellen, muss das Original im Normalfall nicht verändert werden.

Oh sry, ich habe mich mit dieser Aussage nur auf den operator= bezogen,
und mit kopieren meinte ich diesem Fall zuweisen.
mein Fehler

Nexus

Dweb schrieb:

Und aufgrund dieses Konfliktes muss dies der Programmiere handhaben.
richtig so ?^^

Der Normalfall bei Objekten mit konstanten Membern ist wie angetönt eher, dass keine Zuweisungs-Semantik implementiert wird. Falls diese trotzdem erwünscht ist, sollte man meiner Meinung nach die Member veränderlich machen.

Oder sag mir, wie du den Zuweisungsoperator straightforward implementieren würdest (ohne Const-Wegcasten, Placement New oder solche Sachen).

naja, angenomman ich habe Attriubte die nicht konstant sind und welche die konstant sind... dann würde eine Zuweisung ja theoretisch Sinn machen.

Und in der operator= Funktion brauche ich die die const-Attriubte ja nich beachten.

@nexus

Nexus

Aber wieso sollte man nur einen Teil des Objekts zuweisen? Das führt lediglich zu inkonsistenen Objektstati.

Grundsätzlich sollte man beim Design eigener Klassen gewisse Konventionen einhalten. Dazu gehört zum Beispiel, dass zwei Objekte nach einer Kopie oder Zuweisung gleich sind (dadurch zeichnet sich ja ein Kopiervorgang aus).

Klar, es gibt auch berechtigte Ausnahmen (z.B. Move-Semantik wie bei std::auto_ptr ), aber die bringen genau aus dem Grund, dass sie nicht die intuitiven Erwartungen erfüllen, eine Menge Einschränkungen mit sich (z.B. bezüglich Speicherung in STL-Containern).

Nexus schrieb:

Aber wieso sollte man nur einen Teil des Objekts zuweisen? Das führt lediglich zu inkonsistenen Objektstati.

da hast du recht, das stimmt nat.

gut nun habe ich wieder was gelernt.
danke euch