std::string nachprogrammieren?

[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.

[Shade Of Mine]

otze schrieb:

wartet mal, wär der op+ als non-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.

Wieso?
Du musst ja eben _nicht_ die Klasse ändern.
Bestes Beispiel ist zB eine string Klasse die einen op+ auch für std::string anbietet:

MyString operator+(MyString a, std::string const& b)
{
  a+=b.c_str();
  return a;
}

Wir haben einen op+ für einen neuen Typen (std::string) geschrieben, ohne die implementierung von MyString anfassen zu müssen.

[otze]

arrgh richtig gedacht falsch geschrieben,man sollte nich schreibenw enn man müde ist.
sorry, wird geedited.
wieso mach ich heute schon den ganzen tag solche fehler

[SirLant]

otze schrieb:

wieso mach ich heute schon den ganzen tag solche fehler

Weil du müde bist

SCNR

[otze]

lol stimmt....
vielleicht sollte ich für heute c++ an den nagel hängen und mir dafür ducktales folgen reinziehen...aber das is offtopic