Zuweisungsoperator Überladung

Th69

Aufs reale Leben bezogen, würde ich für eine Konto-Klasse den Zuweisungsoperator wohl verbieten (sonst könnte man ja einfach das Guthaben ver-x-fachen ;-)...

Berzerk

Achso ok danke

volkard schrieb:

Aber ich denke da anders. Zuweisungen dürfen gerne void zurückgeben, denn man mag Zuweisungen nie im selben Ausdruck noch weiterverwenden.

Denkst du wirklich, dass
- Standardkonformität vergeben (Container)
- Keine Mehrfachzuweisungen (a=b=c) erlauben
- Auf Konsistenz mit Builtin-Types und der restlichen C++-Community verzichten
es wert ist, ein klein bisschen Schreibarbeit (return *this + type& statt void) zu sparen?

Falls ja, stehst ziemlich alleine da.

volkard

shitstorm schrieb:

volkard schrieb:

Aber ich denke da anders. Zuweisungen dürfen gerne void zurückgeben, denn man mag Zuweisungen nie im selben Ausdruck noch weiterverwenden.

Denkst du wirklich, dass
- Standardkonformität vergeben (Container)
- Keine Mehrfachzuweisungen (a=b=c) erlauben
- Auf Konsistenz mit Builtin-Types und der restlichen C++-Community verzichten
es wert ist, ein klein bisschen Schreibarbeit (return *this + type& statt void) zu sparen?

Falsche Sichtweise das:
- Man muss nicht jeden Mist mitspielen.
- Zuweisungsauswertung (if(a=b)) verbieten. Und wer meint, a=b=c zu brauchen, gehört gefeuert.
- Vorreiter sind halt nicht umfassend konsistent mit der Community. Konsistenz mit int, wozu denn? Doch nur für deine albernen Mehrfachzuweisungen. Um die Schreibarbeit gehts mir sicher nicht.

shitstorm schrieb:

Falls ja, stehst ziemlich alleine da.

Nein, hast mich komplett falsch eingeschätzt. Und ja, ich weiß, daß ich ziemlich alleine dastehe. Das macht aber nix, ich weiß, daß sich void als Rückgabetyp von op= und op++ sehr gut macht.

volkard schrieb:

- Zuweisungsauswertung (if(a=b)) verbieten.

Mein Compiler warnt mich davor. Wenn ich es doch will, schreib ich if((a=b)) und bin froh, dass es geht.

volkard schrieb:

Um die Schreibarbeit gehts mir sicher nicht.

Worum denn dann? Der einzige haltbare Grund scheint zu sein Mehrfachzuweisungen zu verbieten und (Kol2=Kol).guthaben. Missbrauch verhindern in dem man künstliche Limitationen einführt, wie Java.

volkard schrieb:

ich weiß, daß sich void als Rückgabetyp von op= und op++ sehr gut macht.

Ich gebe zu, dass ich desöfteren op++ dereferenziere und ich finde den Code danach lesbarer.

volkard

shitstorm schrieb:

volkard schrieb:

- Zuweisungsauswertung (if(a=b)) verbieten.

Mein Compiler warnt mich davor. Wenn ich es doch will, schreib ich if((a=b)) und bin froh, dass es geht.

Zeig mir sinnvolle Mehrfachzuweisungen.

Nicht dass die Funktion an sich Sinn macht, aber hier gleich op++ und op= gemischt:

template <typename IterIn, typename IterOut1, typename IterOut2>
std::pair<IterOut1, IterOut2>
simultaneous_copy(IterIn first, IterIn last, IterOut1 dest1, IterOut2 dest2) {
  while	(first != last)
    *dest1++ = *dest2++ = *first++;
  return {dest1, dest2};
}

Die Funktion ist gar nicht so nutzlos. Zum Beispiel könnte man man: tee so nachprogrammieren:

int main(int argc, const char *argv[])
{
  if (argc != 2) return -1;
  if (std::ofstream out{argv[1]})
    simultaneous_copy(std::istreambuf_iterator<char>(std::cin),
                      {},
                      std::ostreambuf_iterator<char>(out),
                      std::ostreambuf_iterator<char>(std::cout));
  else
    return -2;
}

volkard

shitstorm schrieb:

Nicht dass die Funktion an sich Sinn macht, aber hier gleich op++ und op= gemischt:

template <typename IterIn, typename IterOut1, typename IterOut2>
std::pair<IterOut1, IterOut2>
simultaneous_copy(IterIn first, IterIn last, IterOut1 dest1, IterOut2 dest2) {
  while	(first != last)
    *dest1++ = *dest2++ = *first++;
  return {dest1, dest2};
}

Und das Erhöhen ging echt nicht ein Zeilchen später?
Ich bezweifle, daß deine Version lesbarer ist. Allenfalls dadurch, daß man sich so freut, so komplizierte Zeilen basteln zu können und sie deshalb sehr mag.

K&R-strcpy:

while(*dst++=*src++);

Hier hat's tatsächlich eine gewisse Eleganz, daß man den Nullterminator nicht nach der Schleife noch dranbasteln muss.

volkard

Übrigens würde ich Minuszahlen als main-return vermeiden, 0,1,2 statt 0,-1,-2 gehn auch. Und gehn dann sogar auf anderen Betriebssystemen.

volkard schrieb:

Übrigens würde ich Minuszahlen als main-return vermeiden, 0,1,2 statt 0,-1,-2 gehn auch. Und gehn dann sogar auf anderen Betriebssystemen.

Aus welchem Grund meidest du dort Minuszahlen?

Skym0sh0

Also ich empfehle ja

return 0x0;

*duck'n'run*

volkard

out schrieb:

volkard schrieb:

Übrigens würde ich Minuszahlen als main-return vermeiden, 0,1,2 statt 0,-1,-2 gehn auch. Und gehn dann sogar auf anderen Betriebssystemen.

Aus welchem Grund meidest du dort Minuszahlen?

Weil DOS sie mißinterpretierte, -1 war 255 und so. Weil ich lieber 0 1 2 3 in die Doku schreibe, Minuszahlen nerven doch nur den Benutzer. Und weil ich einfach nicht irgendwann Plattformabhängig returnen will, wenn irgendwo die int-size sich ändert.

volkard schrieb:

Und weil ich einfach nicht irgendwann Plattformabhängig returnen will, wenn irgendwo die int-size sich ändert.

Der Standard spricht nur von 0 und non-null. Was das Betriebssystem mit dem genauen Int-Wert macht, ist sowieso platformabhängig (<-- kein Nomen).