C++ Sonderzeichen als Funktionsnamen? (+,#,& ...)

[1668mib]

"The operation x << n shifts the value of x left by n bits."
Naja egal was ich mache, aber ich verändere x in Abhängigkeit von n - ich bleibe dabei, dass dabei die ursprüngliche Bedeutung des Operators geändert wurde. Dass es praktisch ist, keine Frage...

Aber wieso mach ich eigentlich keine Addition einfach? Ich füge was zum Stream dazu - ist doch klar, dass das schreiben heißt.. man kann diskutieren wie man will, ich wollte nur aufzeigen, dass auch was auch Ikonen nicht immer mit allem recht haben, was sie sagen....

 

[Fonce]

Das nicht nutzen des + für diese Operation hat aber den Vorteil, das du z.B.

cout << foo+bar << endl;

Schreiben kannst und Additionen zweier Variablen wohl deutlich häufiger bei einer Ausgabe vorkommen wird als das Verschieben um n Bits.
Wenn wäre ein gleich meiner Meinung nach sinniger gewesen(wenn man meint man müsste es ändern), den schließlich weise ich der Ausgabe neue Werte zu und das = dient nun mal einer Zuweisung.

 

[1668mib]

@Fonce: Und genau das ist doch der Punkt, warum ich sage, dass die Operatoren << und >> bei den Streams falsch eingesetzt werden. Das heißt aber nicht, dass ich sage, dass es nicht okay so ist wie es ist...

Und das mit der Verkettung hat gar nichts damit zu tun, das könnte man mit dem Plus-Operator genauso ohne Probleme machen... ich hab ja nichts von einer Zuweisung gesagt...

Edit:
Ach sorry, hatte dich bissl falsch verstanden, ich weiß jetzt was du meinst, aber man kann ja Klammern setzen (was eh nicht verkehrt ist wegen Reihenfolgen usw ^^)

 

[antred]

Wenn wäre ein gleich meiner Meinung nach sinniger gewesen(wenn man meint man müsste es ändern), den schließlich weise ich der Ausgabe neue Werte zu und das = dient nun mal einer Zuweisung.

So? Und wie machst du das dann, wenn du was aus einem istream heraus holen möchtest?


Neben << und >> wirken alle Alternativen noch viel unpraktischer.

 

[Fonce]

ähm wie wäre es mit

foo = cin

Nur mal so, andere Sprachen schaffen eingaben ja auch ohne >> zu benutzen^^
EDIT:
Mein Beispiel oben würde auch eher zu der sonst geltenden Zuweisungssyntax passen welche bei C/C++ nun mal eine Zuweisung von Recht nach Links vorsieht.
Ich sage außerdem ja auch das ich es nicht geändert haben möchte, nur das man es wenn hätte so gestallten sollen, wenn man nicht << und >> nutzt.

 

[Yuuri]

foo = cin

Und was passiert dann mit:

istream *tmp1, *tmp2;
// ...
tmp1 = tmp2;
// ...

Die Zuweisung bleibt dann unterm Tisch oder verhält sich vollkommen anders als die von dereferenzierten Objekten? Oder wird man zu tmp1( tmp2 ) gezwungen? Nein danke, dann doch lieber von vorn herein <</>>.

 

[1668mib]

Geht ja nicht um das Abschaffen der Operatoren <</>>, ging nur darum, dass die nicht wirklich im eigentlichen Sinne genutzt werden bei streams - nicht mehr, aber auch nicht weniger :-)

 

[antred]

ähm wie wäre es mit

foo = cin

Wie bitte soll das funktionieren?? Für Klassen kannst du den = operator natürlich problemlos für "Zuweisung" eines istream-Objektes überladen, aber was machst du mit den trivialen Datentypen (also double, int, etc.)? Dein Vorschlag würde bedeuten, daß die Regeln der Sprache selbst geändert werden müßten, nicht nur die Syntax der Standard C++ Bibliothek.

Des weiteren würde das Kaskadieren, wie es mit >> und << möglich ist, bei dir dann so aussehen??

int a = 13;
std::cout = "bla bla bla ... Integerwert: " = a = "\n";

Und das vergewaltigt ja wohl die althergebrachte Semantik des Zuweisungsoperators ein wenig mehr als es iostreams mit den Schiebeoperatoren tun (mal abgesehen davon, daß es sowieso nicht funktionieren würde).

 

[Fonce]

Das zusammensetzen des String könnte man dann durch den + Operator darstellen, wodurch auch seine Bedeutung nicht wirklich drunter leiden würde.
In Java und python wird dies nämlich auch genau auf diese Weise gehandhabt.

std::cout = "bla bla bla ... Integerwert: " + a + "\n";

bzw.

std::cout = "bla bla bla ... Integerwert: " + a + endl;

Und nochmal für alle, ich will es doch gar nicht ändern!
Ist 1668mib eigentlich der einzige der Versteht was ich meine?

 

[antred]

Das zusammensetzen des String könnte man dann durch den + Operator darstellen, wodurch auch seine Bedeutung nicht wirklich drunter leiden würde.

Und dadurch haufenweise temporaries erzeugen. Zusätzlich müßte es dann eine Überladung des operator + für jede mögliche Kombination von String und <anderer Typ> geben.

Und nochmal für alle, ich will es doch gar nicht ändern!
Ist 1668mib eigentlich der einzige der Versteht was ich meine?

Das ist mir schon klar, aber du hattest gesagt, der Zuweisungsoperator wäre eine sinniger Wahl gewesen, und ich will dir zeigen, daß er das eben nicht wäre.
Unter den bestehenden Regeln und Einschränkungen der Sprache C++ sind << und >> wirklich die sinnvollste Wahl.

 

[Fonce]

Wieso sollten da mehr temporäre Dinge entstehen? Das ist nur eine Änderung an der Syntax, was der Compiler daraus erzeugt, ist eine ganz andere Sache!

 

[antred]

Wieso sollten da mehr temporäre Dinge entstehen? Das ist nur eine Änderung an der Syntax, was der Compiler daraus erzeugt, ist eine ganz andere Sache!

Du möchtest mit Operator + Sachen zusammenfügen, und das Ergebnis sollen wieder Strings sein. Hast du doch gesagt, oder? Für das Zusammenspiel mit einer Klasse Bla müßte der Operator also so aussehen.

const std::string operator + ( const Bla& lhs, const std::string& rhs )
{
    // neuen Sting erstellen
    // ...

    // und Ergebnis an Anrufer zurückgeben
    return resultString;
}

// und das gleiche natürlich noch mal für linke und rechte Seite vertauscht...
const std::string operator + ( const std::string& lhs, const Bla& rhs )
// ....

Wenn du jetzt also schreibst

Bla blubber;

std::cout = std::string( "Hier ist der Wert von blubber: " ) + blubber + ". bla bla bla.\n";

dann wird erst mal das 1. Glied und blubber aufaddiert, was dann einen neuen String liefert ... dann wird dieser neue String und das letzte Glied aufaddiert ... was natürlich wieder einen neuen String ergibt, und erst dann wird das Ergebnis an std::cout übergeben. Das sind in diesem Fall 2 zusätzliche temporaries, die du mit << nicht hättest.

 

[Fonce]

Statt aus dem ganzen erst einen kompletten String zu erstellen, könnte man diese aber auch einfach direkt nacheinander auf den output schreiben...
Logisch würde man dann schreiben

weise OUTPUT erst ELEMENT_1 dann ELEMENT_2 dann ELEMENT_3 usw. zu

bzw.

schreibe auf OUTPUT erst ELEMENT_1 dann ELEMENT_2 dann ELEMENT_3 usw.

 

[antred]

Wie würde das in C++ konkret aussehen? Mir fällt nur folgendes ein:

std::cout = "Hier ist der Wert von blubber: ";
std::cout = blubber;
std::cout = ". bla bla bla.\n";

Kaskadieren könnte man dann eben nicht mehr.

 

[Fonce]

So wie ich es oben mit dem + geschrieben habe.
Es würde syntaktisch eine Kaskadierung darstellen, würde aber nicht anderen machen als die Dinge direkt auf den output zu schreiben. In der Praxis würde das genau das Ergebnis generieren, was du logisch erzielen willst.
Es ist ja auch nicht so, dass alles was du an Code schreibst genau so vom Compiler übersetzt wird.

EDIT:
So jetzt aber erstmal Fußball gucken

 

[antred]

So wie ich es oben mit dem + geschrieben habe.

Du meinst das hier?

std::cout = "bla bla bla ... Integerwert: " + a + endl;

Es würde syntaktisch eine Kaskadierung darstellen, würde aber nicht anderen machen als die Dinge direkt auf den output zu schreiben.

Also vielleicht habe hier nur einen Denkfehler, aber ich sehe einfach nicht, wie das in C++ gehen soll ... also mit deiner Syntax jedes Glied einzeln, fein eins nach dem anderen auf cout schreiben ... ohne temporaries.
Nach den Regeln von C++ hat der + Operator Vorrang vorm = Operator. Das heißt also, die Sache würde in dieser Reihenfolge ablaufen (wie ich's oben schon mal beschrieben habe):

(Pseudocode)

1) ( "bla bla bla ... Integerwert: " + a ) -> temporary_1
2) ( temporary_1 + endl ) -> temporary_2
3) std::cout = temporary_2

Wenn jetzt Teiloperationen 1) und 2) keine temporaries erzeugen sondern direkt in cout reinschreiben sollten, dann bräuchten sie auf jeden Fall eine Referenz auf cout. Jedoch ist cout an den Teiloperationen 1) und 2) überhaupt nicht beteiligt, also fehlt diese Referenz auf cout, ergo geht das so, wie du es dir vorstellst einfach nicht.

Ansonsten erklär mir bitte, wie du dir das vorstellst.

 

[7H3 N4C3R]

So wie ich es oben mit dem + geschrieben habe.
Es würde syntaktisch eine Kaskadierung darstellen, würde aber nicht anderen machen als die Dinge direkt auf den output zu schreiben. In der Praxis würde das genau das Ergebnis generieren, was du logisch erzielen willst.
Es ist ja auch nicht so, dass alles was du an Code schreibst genau so vom Compiler übersetzt wird.)

Geht nicht (sinnvoll), weil operator= aus gutem Grund von rechts nach links gruppiert. Durch die links-nach-rechts Gruppierung wird bei operator>> das ausgebende Objekt an alle anderen in der Kette weitergereicht.

Links-nach-rechts bzw. rechts-nach-links Gruppierung ist an die Operatoren gebunden und nicht veränderbar.