Ist es sinnvoll heute noch C++ anzufangen?

[JustAnotherNoob]

eigentlich wollte ich mich ja aus Diskussionen raushalten, in denen fricky mitschreibt, weil es ohne Argumente gegen die man argumentieren kann langweilig ist, aber gut...

Erstmal zu audacia:

cout.write ("foo").write (42).write (3.14159).write (endl);

findest du das übersichtlich? Macht man in Java btw. auch nicht, da definiert man ja einen Sonderfall für +, weil es ja übersichtlicher ist den Operator zu überladen, aber natürlich nur in dem Fall. Es ist ja undenkbar, dass es sonst auch mal nützlich sein könnte.
Hey fricky, wolltest du nicht ein Beispiel für sinnvolle Operatorenüberladung außerhalb mathematischer Bibliotheken? Wie wärs mit Stringconcatenation.
Das ist ein Beispiel, wenn du auch nur annähernd logisch denken könntest wärst du auf den Gedanken gekommen, dass ein Beispiel schon ausreicht um zu legitimieren, dass man es benutzen kann aber nicht muss. Aber bitte, wenn du denkst, dass du nicht in der Lage bist auf Operatorenüberladung in sinnlosen Fällen zu verzichten, bitte.. dann ist Java vielleicht gut für dich, aber verweise hier bitte nicht auf Andere.

nicht verbieten, sondern garnicht erst einbauen, weil's einfach nichts bringt. die vorteile können die nachteile nicht aufwiegen, also lässt man's besser weg.

bla bla bla... welche Nachteile? dass man einen schlechten Namen vergeben kann? Das kann man auch in Java, es ist kein Unterschied, aber das willst du ja nicht verstehen. s.o.

Dass Operatorenüberladung in C# wieder eingebaut wurde und auch sonst in so ziemlich allen modernen Sprachen (z.B. Scriptsprachen wie Ruby und Python) enthalten ist zeigt doch schonmal, dass es keine C++ Erscheinung ist, viel eher ist es eine Javaabnormalität es nicht zu haben. Ein gescheitertes Experiment, wenn du es so willst.

Jedoch halte ich die Verwendung in den C++-Streams für unangemessen.

Ich finds praktisch, weil es übersichtlich wird und es ist ja nicht so, dass es missverständlich wäre, denn das ist das womit jeder C++ Programmierer zu erst konfrontiert wird.
Bei einer X-Beliebigen Bibliothek könnte man es vielleicht eher kritisieren, aber durch die verbreitete Nutzung in der Standardbibliothek bekommen die Streamoperatoren in C++ eigentlich schon eine gleichberechtigte Bedeutung mit den Shiftoperatoren, so wie es in Java z.B. mit + für Strings ist. (Wäre es besser wenn << und >> in der Sprache für Strings nochmal definiert wäre? Wäre das selbe wie + in Java und es wäre unflexibler)

Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz.

Ja, man muss es gelegtl. Klammern, in Java gibt es ähnliche Probleme, wenn man nicht-Strings mit + zusammenhängen will um sie auszugeben, von daher.. ähnliches Phänomen, das write Beispiel würde es verhindern, aber ich finds unübersichtlich. Man kann auch einfach die Argumente grundsätzlich Klammern, wenn einem das wirklich Probleme macht, es ist nur eine Frage der Gewohnheit. Die Sprache muss das deswegen ja nicht verbieten.

[Dravere]

audacia schrieb:

Jedoch halte ich die Verwendung in den C++-Streams für unangemessen.

Damit wir uns verstehen, ich halte sogar die C++ Streams für Überholungsbedürftig. Ob man dann noch in einer neuen Version die Bitshift Operatoren verwenden sollte, würde ich sehr gerne auch diskutieren.

Die Diskussion ist für mich nur nicht von solch hoher Priorität.

Aber naja, damit driften wir dann zu weit ab. Also zurück zum Thema:

audacia schrieb:

Zusätzlich versteht auch jeder C-Programmierer, daß es da nicht um Bitshifting geht

Jetzt müssen wir schon eine Sprache wegen +fricky anpassen? Soweit kommt es noch. Aber der versteht es ja auch dann noch nicht, also vergiss diese C Programmierer à la +fricky.

Grüssli

[Tippgeber]

JustAnotherNoob schrieb:

Erstmal zu audacia:

cout.write ("foo").write (42).write (3.14159).write (endl);

findest du das übersichtlich? Macht man in Java btw. auch nicht, da definiert man ja einen Sonderfall für +, weil es ja übersichtlicher ist den Operator zu überladen, aber natürlich nur in dem Fall. Es ist ja undenkbar, dass es sonst auch mal nützlich sein könnte.
Hey fricky, wolltest du nicht ein Beispiel für sinnvolle Operatorenüberladung außerhalb mathematischer Bibliotheken? Wie wärs mit Stringconcatenation.
Das ist ein Beispiel, wenn du auch nur annähernd logisch denken könntest wärst du auf den Gedanken gekommen, dass ein Beispiel schon ausreicht um zu legitimieren, dass man es benutzen kann aber nicht muss. Aber bitte, wenn du denkst, dass du nicht in der Lage bist auf Operatorenüberladung in sinnlosen Fällen zu verzichten, bitte.. dann ist Java vielleicht gut für dich, aber verweise hier bitte nicht auf Andere.

Das Plus ist schlecht dafür und ich denke, dass Java das Plus auch nur hat, weil std::string es verwendet. Wer noch nie in einer Sprache programmiert hat in der das Plus für Stringkonkatenation steht, aber schon einmal etwas theoretische Informatik mitbekommen hat wird da sofort an das Oder aus einem regulären Ausdruck denken und nicht daran, dass hier eine Konkatenation gemeint ist.
Schöner wäre es wie auch in Perl den Punkt zu benutzen, der kommt dem vertikal zentrierten Multiplikationspunkt am nächsten, der auch in der theoretischen Informatik meist für die Konkatenation benutzt wird. Aber den darf man in C++ ja aus guten Gründen nicht überladen, weshalb man sich dann wohl auf + geeinigt hat.

[audacia]

JustAnotherNoob schrieb:

cout.write ("foo").write (42).write (3.14159).write (endl);

findest du das übersichtlich?

Nein. Übersichtlich finde ich das:

printf ("foo %d %f", 42, 3.14159);

[+fricky]

Dravere schrieb:

+fricky schrieb:

nicht verbieten, sondern garnicht erst einbauen, ...

Und wo ist der Unterschied?

verbieten = jemandem etwas untersagen, möglicherweise unter androhung von strafe oder ähnlichen konsequenzen.
einbauen = etwas zu etwas anderem hinzufügen, so daß es bestandteil dessen wird.

audacia schrieb:

Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz.

nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.

Dravere schrieb:

audacia schrieb:

Zusätzlich versteht auch jeder C-Programmierer, daß es da nicht um Bitshifting geht

Jetzt müssen wir schon eine Sprache wegen +fricky anpassen?

nur das abschaffen der vergewaltigten shifts, würde mir aber lange nicht reichen.

[quniox]

Also um mal auf das Ausgangsposting zurückzukommen, ich würde C++ heutzutage NICHT mehr einsetzen. Einen triftigen Grund gibt es für die Sprache nicht mehr, da hast du schon Recht. In den späten 80'ern und den 90'ern mag C++ sinnvoll gewesen sein, aber heutzutage gibt es einfach bessere Sprachen.

Das Verhängnis von C++ ist halt, dass es eine Sprache für alles sein wollte und so weder am einen noch am anderen Ende die Bedürfnisse vernünftig zufriedenstellen kann. Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.

[+fricky]

quniox schrieb:

Also um mal auf das Ausgangsposting zurückzukommen, ich würde C++ heutzutage NICHT mehr einsetzen. Einen triftigen Grund gibt es für die Sprache nicht mehr, da hast du schon Recht. In den späten 80'ern und den 90'ern mag C++ sinnvoll gewesen sein, aber heutzutage gibt es einfach bessere Sprachen.

Das Verhängnis von C++ ist halt, dass es eine Sprache für alles sein wollte und so weder am einen noch am anderen Ende die Bedürfnisse vernünftig zufriedenstellen kann. Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.

^^diese posting bringt alles auf den punkt
leute, wir können den thread hiermit als beendet betrachten

[enten_wickler]

Der Lowlevel Entwickler meidet es, der Highlevel Entwickler ebenfalls.

Der Entwickler in der Praxis benutzt es.

[C++-Progger, Der]

+fricky schrieb:

audacia schrieb:

Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz.

nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.

Was passiert deiner Meinung nach denn in diesem Fall?

[u_ser-l]

scheinbar ist es gerade der Kompromiß aus nicht bis in die letzte Konsequenz umgesetzten Prinzipien, die eine Sprache praxistauglich machen. Bei C++ die Mischung aus angedeuteter OO, mit low-level-features bei Bedarf sowie C-Kompatibilität. Reine OO unter Beibehaltung der C-Kompatibilität wäre wohl sowieso unmöglich. Objekte und Adreßarithmetik, Zeiger und GC, das paßt nicht.

Paradigmenreine Sprachen haben dagegen mit Akzeptanzproblemen zu kämpfen oder gelten als ewige "Sprache der Zukunft", das war schon immer so und wird scheinbar auch so bleiben.

"Die einen Sprachen werden gelobt, die anderen verwendet" - wer hat das gesagt? Ich weiß, wer etwas Ähnliches gesagt hat, hat sogar mit C++ zu tun.

[JustAnotherNoob]

nein, der absolute c++ favorit von +fricky ist 'cout << x;' wobei x ein 'volatile int' grösser 1 ist. das ist richtig lustig und hat auch was mit überladung zu tun.

Gib mal einen Verweis auf den Standard, denn wenn das was seltsames machen soll, dann ist der GCC nicht Standardkonform, denn das hier:

#include <iostream>

using namespace std;

int main()
  {
  volatile int i(2);
  cout << i;
  }

gibt bei mir 2 aus.

[+fricky]

sorry für die verwirrung, es muss natürlich ein pointer sein:

volatile int *p = (volatile int*)0x1234;
    printf ("%p\n", p);  // ok
    cout << p << endl;   // 1?

[Tippgeber]

+fricky schrieb:

sorry für die verwirrung, es muss natürlich ein pointer sein:

volatile int *p = (volatile int*)0x1234;
    printf ("%p\n", p);  // ok
    cout << p << endl;   // 1?

Schönes Beispiel, will man allerdings die referenzierte Adresse ausgeben so *muss* man diesen nach void* casten. Damit will ich nicht behaupten, dass du unrecht hast, sondern, dass hier ein anderer Fallstrick vorliegt (jeder würde ja intuitiv erwarten, dass man einen Zeiger wie alles andere auch ausgeben kann).

[tntnet]

+fricky schrieb:

sorry für die verwirrung, es muss natürlich ein pointer sein:

volatile int *p = (volatile int*)0x1234;
    printf ("%p\n", p);  // ok
    cout << p << endl;   // 1?

Wie sinnvoll ist es, den Wert eines Zeigers auszugeben? Ich sehe keinen praktischen Nutzen bzw. praktischen Nachteil darin. Da gibt es sicher andere interessante Konstrukte, um C++ zu kritisieren.

Hier wird der Zeiger zur Ausgabe implizit in einen bool gecastet. Nicht unbedingt sinnvoll oder intuitiv, aber nicht wirklich problematisch.

[+fricky]

Tippgeber schrieb:

...will man allerdings die referenzierte Adresse ausgeben so *muss* man diesen nach void* casten.

aber seltsam: mit 'nem int*, ohne 'volatile' davor, gibts die erwartete (richtige) ausgabe auch ohne cast.

tntnet schrieb:

Wie sinnvoll ist es, den Wert eines Zeigers auszugeben? Ich sehe keinen praktischen Nutzen bzw. praktischen Nachteil darin.

wenn man c++-fanboys zeigt, welch komische faxen mit ihrer sprache möglich sind, wird oft die sinnhaftigkeit der gesamten aktion in frage gestellt. woran liegts? selbstverständlich ist es manchmal sinnvoll, den wert eines zeigers auszugeben.

tntnet schrieb:

Da gibt es sicher andere interessante Konstrukte, um C++ zu kritisieren.

ich weiss. manche füllen 90% ihres webauftritts damit.

tntnet schrieb:

Hier wird der Zeiger zur Ausgabe implizit in einen bool gecastet.

was ja wohl das verkehrteste überhaupt ist.

[JustAnotherNoob]

was ja wohl das verkehrteste überhaupt ist.

Richtig, aber das hat mit Operatorenüberladung grad mal gar nix zu tun, wie du behaupted hast, sondern ist ein Nachteil der starken Typisierung, die 1. auch in deinem geliebtem Java existert und 2. mehr Vor- als Nachteile bringt.

wenn man c++-fanboys zeigt, welch komische faxen mit ihrer sprache möglich sind, wird oft die sinnhaftigkeit der gesamten aktion in frage gestellt. woran liegts? selbstverständlich ist es manchmal sinnvoll, den wert eines zeigers auszugeben.

wenn man einem java-fanboy zeigt, welche Dinge mit Java alles nicht möglich ist, wird oft die Sinnhaftigkeit der ganzen Aktion in Frage gestellt, woran liegts? Selbstverständlich ist es manchmal sinnvoll Operatoren zu überladen.

[knivil]

Allgemeiner Quark ...

[+fricky]

JustAnotherNoob schrieb:

Richtig, aber das hat mit Operatorenüberladung grad mal gar nix zu tun, wie du behaupted hast...

indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.

JustAnotherNoob schrieb:

sondern ist ein Nachteil der starken Typisierung, die 1. auch in deinem geliebtem Java existert und ...

in einer stark typisierten sprache wäre ein cast von 'volatine int*' nach bool überhaupt nicht möglich. aber kannst gern mal selbst ausprobieren, was du in Java alles in einen boolean casten kannst.

[JustAnotherNoob]

indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.

Das wäre bei einer anderen Funktion nicht anders, deswegen hats mit Operatorenüberladung nichts zu tun.

in einer stark typisierten sprache wäre ein cast von 'volatine int*' nach bool überhaupt nicht möglich. aber kannst gern mal selbst ausprobieren, was du in Java alles in einen boolean casten kannst.

Ja, sorry, mein Fehler. Es liegt jedenfalls an der stärkeren Typisierung als in C.
Wie auch immer, es ist jedenfalls eine Schwäche von C++, aber keine, die man besonders oft zu spüren bekommt. Dass C++ perfekt ist hat wohl niemand behauptet.

[+fricky]

JustAnotherNoob schrieb:

indirekt schon. schliesslich versagt hier cout.operator<<() völlig und der benutzer wundert sich.

Das wäre bei einer anderen Funktion nicht anders, deswegen hats mit Operatorenüberladung nichts zu tun.

natürlich hat es damit zu tun. bei 'ner funktion: printThatFuckingPointerValue(void *p) siehste allein schon am namen, was sie machen soll. ein operator<< mit 1000 überladungen, der eigenmächtig (und fälschlicherweise) pointer in 'bools' castet, ist einfach nur mist.
zu op-überladungen schau auch mal hier: http://cafe.elharo.com/blogroll/operator-overloading-considered-harmful/

JustAnotherNoob schrieb:

Dass C++ perfekt ist hat wohl niemand behauptet.

das würd wohl auch keiner wagen, so weit wie C++ von perfektion entfernt ist.