std::string nachprogrammieren?

Jester

Dann versteh's doch bitte noch.
So wie prolog das beschrieben hatte wird bei

a+5;

a verändert. Und das ist vollkommen unerwartet. Also wenn schon, dann ein neues Objekt zurückgeben, keine Referenz. Das bitte nur beim op= oder den op+= und Konsorten.

So, warum jetzt kein Member?
Weil dann auf dem linken Parameter keine Konvertierung durchgeführt werden kann.

Warum sollte denn

"Hallo"+5; erlaubt sein, aber 5+"Hallo" nicht?

MfG Jester

Shlo

Irgendwie erzählst du mir nicht Neues, denn das wurde von mir bereits oben gepostet...

Warum sollte denn

"Hallo"+5; erlaubt sein, aber 5+"Hallo" nicht?

macht keinen Sinn, warum sollte ich einen String-Literal mit einem int addieren? Zudem muss beim Überladen von Operatoren, einer der Parameter von Class-Type sein.

SideWinder

Es ist so, wenns dich interessiert warum ließ ecp kapitel 23...

class myclass
{
    friend myclass operator + (const myclass& lhs, const myclass& rhs);
};

myclass operator + (const myclass& lhs, const myclass& rhs)
{
    myclass ret;
    // ret = lhs + rhs
    return(ret);
}

So schauts aus.

MfG SideWinder

Shlo

SideWinder schrieb:

So schauts aus.

Du auch nicht...

prolog

Hallo,

@alle Nachposter
Sry habs mit dem Zuweisungsoperator verwechselt.

SideWinder

Shlo schrieb:

SideWinder schrieb:

So schauts aus.

Du auch nicht...

Warum er kein Member sein soll ist doch irgendwo klar. Nehmen wir an ein CTor ist nicht explicit (ist ja sehr oft der Fall), dann gibts plötzlich Probleme die mit einem globalen op nicht passieren.

MfG SideWinder

Jester

gelöscht

Jester

Shlo schrieb:

Warum sollte denn

"Hallo"+5; erlaubt sein, aber 5+"Hallo" nicht?

macht keinen Sinn, warum sollte ich einen String-Literal mit einem int addieren? Zudem muss beim Überladen von Operatoren, einer der Parameter von Class-Type sein.

Oh bitte, Hirn einschalten und dann posten. Das war ein Beispiel!
Stell Dir vor, int würde nach string konvertiert werden...

Shade Of Mine

Jester schrieb:

Oh bitte, Hirn einschalten und dann posten. Das war ein Beispiel!
Stell Dir vor, int würde nach string konvertiert werden...

Wozu? Der Code ist doch super.

Warum sollte man " hallo"+1 rechnen wollen? vielleicht um "hallo" zu erhalten?

aber der hauptpunkt ist ja (nochmal für die langsameren)

a+b;
ist legaler code
und
b+a;
nicht

finde ich persönlich verwirrend.
denn mir hat man immer gesagt
a+b == b+a

operator void

Shade Of Mine schrieb:

denn mir hat man immer gesagt
a+b == b+a

Dann ist der operator+ für std::string aber falsch...

... *sich der allgemeinen Klugscheißerei anschließ* sorry

Shade Of Mine

operator void schrieb:

Dann ist der operator+ für std::string aber falsch...

Exakt. + ist für das zusammenhängen von strings nicht wirklich geeignet. Man bräuchte einen eigenen Operator dafür.

SirLant

string sind, aber keine built-in Typen und somit geht das schlecht, gleiches gilt für die streams.

SideWinder

Shade Of Mine schrieb:

operator void schrieb:

Dann ist der operator+ für std::string aber falsch...

Exakt. + ist für das zusammenhängen von strings nicht wirklich geeignet. Man bräuchte einen eigenen Operator dafür.

Imho ist ein solcher Missbrauch erlaubt, und wie bereits erwähnt: Stream-Operatoren erledigen ja auch kein Bitshifting. Ich hätte noch nicht einmal ein Problem damit wenn jemand den ^-Operator für eine Rational-Klasse überlädt und ihn fürs Quadrieren misbraucht.

Ein klein wenig Spaß darf sein.

MfG SideWinder

Shlo

Jester schrieb:

Shlo schrieb:

Warum sollte denn

"Hallo"+5; erlaubt sein, aber 5+"Hallo" nicht?

macht keinen Sinn, warum sollte ich einen String-Literal mit einem int addieren? Zudem muss beim Überladen von Operatoren, einer der Parameter von Class-Type sein.

Oh bitte, Hirn einschalten und dann posten. Das war ein Beispiel!
Stell Dir vor, int würde nach string konvertiert werden...

Wie passend, int in string und auch noch implizit... Viellecht solltest du deinen Hirn einschalten...

SirLant

Shlo schrieb:

Jester schrieb:

Shlo schrieb:

Warum sollte denn

"Hallo"+5; erlaubt sein, aber 5+"Hallo" nicht?

macht keinen Sinn, warum sollte ich einen String-Literal mit einem int addieren? Zudem muss beim Überladen von Operatoren, einer der Parameter von Class-Type sein.

Oh bitte, Hirn einschalten und dann posten. Das war ein Beispiel!
Stell Dir vor, int würde nach string konvertiert werden...

Wie passend, int in string und auch noch implizit... Viellecht solltest du deinen Hirn einschalten...

Irgendwie scheint jedem, außer dir, klar zu sein, dass es sich hier nur um ein Beispiel handelte

Shade Of Mine

Shlo schrieb:

Wie passend, int in string und auch noch implizit... Viellecht solltest du deinen Hirn einschalten...

Nochmal für die ganz dummen:

BigInt128 a=10;
BigInt256 b=5;

cout<< (a+b);
//gibt 15 aus
cout<< (b+a);
//ist ein compiler fehler

Ist es jetzt auch dir klar??

Shlo

Shade Of Mine schrieb:

Shlo schrieb:

Wie passend, int in string und auch noch implizit... Viellecht solltest du deinen Hirn einschalten...

Nochmal für die ganz dummen:

BigInt128 a=10;
BigInt256 b=5;

cout<< (a+b);
//gibt 15 aus
cout<< (b+a);
//ist ein compiler fehler

Ist es jetzt auch dir klar??

Darum geht es nicht, du Pappnase. Wenn man eine Klasse hat, die keine impliziten Konvertierungen durchführt, ist es unnötig den operator+ statisch zu definieren. Jetzt soweit?

Shade Of Mine

Shlo schrieb:

Darum geht es nicht, du Pappnase. Wenn man eine Klasse hat, die keine impliziten Konvertierungen durchführt, ist es unnötig den operator+ statisch zu definieren. Jetzt soweit?

wtf?
der op+ soll immer non member sein.

Das hat mit impliziten Konvertierungen doch nicht zwingend etwas zu tun.

Wenn der op+ member ist, dann ist a+b etwas anderes als b+a. Sofern a und b vom selben Typen sind, ist es vertretbar.

Sobald du aber das ganze erweiterst - also einen op+ für einen fremden Typen bauen musst, erkennt man die sinnlosigkeit des op+ als member. Denn dann hast du auf einmal einen op+ als memeber und einen als non member. Adieu einheitlichkeit.

weiters ist der op+ als member sehr fehleranfällig - denn meistens vergessen die leute ihn const zu machen. Was ja auch logisch ist, denn die leute die einen op+ als member implementieren kennen sich ja nicht so gut aus. sonst würden sie es ja nicht machen.

weiters kommt jetzt die logik dazu. ein op+ als member ist nicht logisch. denn binaere operatoren machen als member keinen sinn. denn warum sollte a+b etwas anderes sein als b+a? mit etwas anderes sein meine ich: eine andere funktion aufrufen. Das verwirrt doch nur. oder implementierst du die vergleichsoperatoren auch alle als member?

ein binaerer operator ist als non member perfekt aufgehoben. da lässt er sich auch so schön um neue typen erweitern.

Aber mir ist natürlich klar, dass ich bei weitem nicht so viel weiss wie du - und deine Argumente (???) ja alle super durchdacht und schön ausführlich erklärt sind - da muss ich mich ja einfach geschlagen geben.

otze

wartet mal, wär der op+ als member nicht auch wider dem ocp?
immerhin müsste man ja die Klasse für jeden neu hinzukommenden Typ für den sie kompatibel sein muss ändern.

SirLant

Wieso sollte die Klasse von einer globalen Funktion abhängig sein, ist doch umgekehrt.