operator+ (nightly build)

groovemaster

m3dus4 schrieb:

sollte ich eher

zahl operator+(const zahl&)

oder

const zahl& operator+(const zahl&)

nehmen?

Weder noch, besser ist, du nimmst

const zahl operator +(const zahl& lhs, const zahl& rhs)

SideWinder

@groovemaster: Wieso const? Nene, wenn schon außerhalb der Klasse dann bitte campers Variante

MfG SideWinder

groovemaster schrieb:

Weder noch, besser ist, du nimmst
const zahl operator +(const zahl& lhs, const zahl& rhs)

wieso keine member-methode?

HumeSikkins

m3dus4 schrieb:

groovemaster schrieb:
Weder noch, besser ist, du nimmst
const zahl operator +(const zahl& lhs, const zahl& rhs)
wieso keine member-methode?

Weil eine solche keine Konvertierungen auf dem linken Operand zulässt. Eine solche ist aber im Sinne der Kommutativität der Addition.

Caipi

SideWinder schrieb:

[...]und noch dazu ein konstantes was die Verkettung von +-Operatoren verbieten würde.

Das verstehe ich nicht. Die Verkettung hat hier doch nichts mit dem Return-Wert zu tun. D.h. auch wenn ich diesen als const deklariere, kann ich verschiedene Werte mit dem op+ verketten.
Also sowas a la

meine_klasse_mit_dem_const_op obj = o1 + o2 + o3 + ...;

machen.

Gruß Caipi

HumeSikkins

Hallo,
für const spricht, dass ein Ausdruck wie (z1 + z2) = z3; zum Compile-Zeit-Fehler wird.

HumeSikkins schrieb:

m3dus4 schrieb:
groovemaster schrieb:
Weder noch, besser ist, du nimmst
const zahl operator +(const zahl& lhs, const zahl& rhs)
wieso keine member-methode?
Weil eine solche keine Konvertierungen auf dem linken Operand zulässt. Eine solche ist aber im Sinne der Kommutativität der Addition.

häh? war das "keine" jetzt zuviel oder verstehe ich dich nicht?

GPC

nein, dass stimmt schon wie er's gesagt hat. wenn du den operator als Member - Funktion implementierst, kann der linke Operand nicht in deine Klasse konvertiert werden. Implementierst du sie global, geht es.

HumeSikkins

m3dus4 schrieb:

HumeSikkins schrieb:
m3dus4 schrieb:
groovemaster schrieb:
Weder noch, besser ist, du nimmst
const zahl operator +(const zahl& lhs, const zahl& rhs)
wieso keine member-methode?
Weil eine solche keine Konvertierungen auf dem linken Operand zulässt. Eine solche ist aber im Sinne der Kommutativität der Addition.
häh? war das "keine" jetzt zuviel oder verstehe ich dich nicht?

Nein, aber der Satz ist trotzdem furchtbar mißverständlich.
Also nochmal anders: angenommen Objekte deiner Klasse zahl lassen sich implizit aus ints erzeugen (zahl besitzt also einen Konvertierungs-Ctor). In diesem Fall kannst du dann sowas schreiben wie:

zahl z = ...;
zahl r = z + 42;

Da Addition kommutativ ist (also a + b <-> b + a), solltest du genausogut auch

zahl z = ...;
zahl r = 42 + z;

schreiben können.
Dies setzt aber voraus, dass der linke Operand (42) zuvor in ein Objekt vom Typ zahl konvertiert wird. Konvertierungen auf dem linken Operand sind aber nur bei freien Funktionen möglich. Nicht aber bei Memberfunktionen. Aus diesem Grund solltest du den operator+ als freie Funktion implementieren.

camper

HumeSikkins schrieb:

Hallo,
für const spricht, dass ein Ausdruck wie (z1 + z2) = z3; zum Compile-Zeit-Fehler wird.

und gegen const spricht, das auch die beste klase sich niemals gänzlich wie ein builtin typ verhalten wird (und im übrigen die meisten klassen ohnehin keine entsprechende vorlage in form von built-ins haben). ich habe noch niemanden gesehen, der mal soeben (z1+z2)=z3 schreibt - wer das tut, kriegt, was er verdient. und es hat ja bekanntlich keinen sinn, sich gegen machiaveli verteidigen zu wollen, der schreibt nähmlich noch ein const_cast dazu, un du hast nichts erreicht.
ein non-const return kann zum beispiel dazu benutzt werden, move-konstruktoren zu implementieren, um so teure kopien, wie sie z.b. mit unbeschränkten zahlentypen auftreten können, zu vermeiden (RVO bzw. NRVO ist nunmal nicht in jeder situation möglich). es gibt ein menge legale und sinnvolle konstrukte, die ein non-const return voraussetzen, manche davon sind fast schon idiomatisch.

HumeSikkins

@camper
ich habe ein const-return nicht empfohlen. Lediglich das gängige Pro-Argument aufgeführt.
In meinen Augen gibt es vier potentielle Signaturen:

1. T operator @ (const T&, const T&);
2. const T operator @ (const T&, const T&);

3. T operator @ (T, const T&);
4. const T operator @ (T, const T&);

Keine davon ist der eindeutige Sieger, da alle ihre Vor- und Nachteile haben. Ich bevorzuge 1. kann aber auch mit 2-4 leben.

groovemaster

camper schrieb:

und gegen const spricht, das auch die beste klase sich niemals gänzlich wie ein builtin typ verhalten wird

Wieso spricht das gegen const? Wenn überhaupt, dann spricht das nur nicht _für_ const.

camper schrieb:

und im übrigen die meisten klassen ohnehin keine entsprechende vorlage in form von built-ins haben

Die meisten Klassen sind ja auch nicht als builtin ausgelegt. Trotzdem gibt es welche, die sich genau so anfühlen.

camper schrieb:

ich habe noch niemanden gesehen, der mal soeben (z1+z2)=z3 schreibt

Da du ja schon einige Zeit hier im Forum aktiv bist, dürftest du mittlerweile mitbekommen haben, auf was für seltsame Ideen Leute so kommen. Deshalb zählt dieses Argument nicht.

camper schrieb:

und es hat ja bekanntlich keinen sinn, sich gegen machiaveli verteidigen zu wollen, der schreibt nähmlich noch ein const_cast dazu, un du hast nichts erreicht.

Ein Stückchen mehr Sicherheit, wenn auch keine vollständige, würde ich nicht als nichts bezeichnen.

camper schrieb:

ein non-const return kann zum beispiel dazu benutzt werden, move-konstruktoren zu implementieren, um so teure kopien, wie sie z.b. mit unbeschränkten zahlentypen auftreten können, zu vermeiden (RVO bzw. NRVO ist nunmal nicht in jeder situation möglich).

Mir ist zwar momentan nicht klar, was du mit "move-konstruktoren" meinst. Aber niemand sagt ja, dass du const Rückgaben verwenden _musst_. IdR verwende ich diese aber, da sie den aufgezeigten Nachteil nicht haben und gegenüber non-const Rückgaben auch keine anderen Nachteile aufweisen (afaik), sofern du nicht auf ein veränderbares Objekt angewiesen bist. Das ist ein bisschen so wie mit der Diskussion um explicit. Ist das momentan nun richtig spezifiziert? Oder sollte lieber jeder dtor explicit sein und dies nur bei Bedarf mit einem implicit Schlüsselwort ausgehebelt werden können?

camper schrieb:

es gibt ein menge legale und sinnvolle konstrukte, die ein non-const return voraussetzen, manche davon sind fast schon idiomatisch.

Ach ja? Dann nenn doch mal ein paar. 10 dürften wohl für den Anfang reichen. Ich bin schon gespannt darauf, was neues kennenzulernen. Ich darf dich nochmal daran erinnern, wir reden über binäre Operatoren und du sagtest "legale" und "sinnvolle".