Ist es sinnvoll heute noch C++ anzufangen?

[Dravere]

+fricky schrieb:

aber das muss schon in böser absicht geschehen.

Dann auch bei der Operatorüberladung.

+fricky schrieb:

mit operatorüberladung schaffst du, ohne viel zutun, verwirrung bei jedem, der nicht dieselben gedankengänge hat, wie du.

Schaffst du auch mit Funktionen, Variablennamen oder Parameternamen.

Diese Argumentation ist so idiotisch:
"Man könnte es falsch einsetzen! VERBIETEN!"

Grüssli

[audacia]

Dravere schrieb:

Dann auch bei der Operatorüberladung.

Dann waren << und >> für C++-Streams volle Absicht?

Aber ernsthaft: Never attribute to malice that which can be adequately explained by stupidity.

[+fricky]

knivil schrieb:

Ich verstehe aber immer noch nicht, was dein Beispiel mir sagen soll.

na, du hast doch erzählt, dass zu Java immer eine riesige klassenbibliothek dazugehört, was aber nicht stimmt. die nano-VM sollte ein gegenbeispiel sein, das deine behauptung widerlegt.

knivil schrieb:

...Genau wie bei "+", sprich: man muss wissen, was man tut (ganz ohne boeswilliger Absicht). Warum habe ich "+" gewaehlt: dieser Operator hat auch mehrere Bedeutungen abhaengig vom Kontext in Java.

ja, du kannst aber bedeutungen und verhalten nicht ändern, d.h. sie sind allen Java-programmierern für alle zeiten bekannt. kein rätselraten wie: 'was bedeutet bloss dieses + hier und welche nebeneffekte hat es?'.

knivil schrieb:

nachtrag: ...und natürlich in assembler. in C++ jedenfalls nicht.

Es gibt bestimmt auch genug Beispiele fuer C++ im embedded Bereich.

einige gibts sicherlich (mir sind zwar nur negativbeispiele bekannt), aber gute gibts bestimmt auch, wahrscheinlich erst ab grösseren MCUs, mit viel mehr wumm und speicher als AVRs.

Dravere schrieb:

Diese Argumentation ist so idiotisch:
"Man könnte es falsch einsetzen! VERBIETEN!"

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.

[EXDW]

Dravere schrieb:

... VERBIETEN!"

hei dravere - wusste gar nicht das du politiker bist #gg

[Dravere]

audacia schrieb:

Dravere schrieb:

Dann auch bei der Operatorüberladung.

Dann waren << und >> für C++-Streams volle Absicht?

Man schiebt etwas in einen Stream rein oder raus. Finde ich eigentlich sehr einleuchtend diese Auswahl. Aber auch wenn die Auswahl schlecht wäre, dann ist es halt eben wie mit einer Funktion, welche einen schlechten Namen hat. Und davon gibt es mehr als genügend! Aber deswegen ruft auch niemand, dass man Funktionen abschaffen soll ... aber naja, hast ja recht ... Wieso habe ich überhaupt darauf geantwortet? Wahrscheinlich weil ich mich nicht mehr beherrschen konnte, ich rege mich immer so auf

Ommmmmmmmmmmm ... ruhig ... ruhig ... die Welt ist nicht verloren ... es war schon immer so ... du musst damit klarkommen ... ommmmmmmm

+fricky schrieb:

nicht verbieten, sondern garnicht erst einbauen, ...

Und wo ist der Unterschied?
Zum Rest des Satzes ... ach vergiss es ... bleib bei deiner Sprache und stör uns nicht.

@Mr Evil,
:p

Grüssli

[audacia]

Dravere schrieb:

Man schiebt etwas in einen Stream rein oder raus. Finde ich eigentlich sehr einleuchtend diese Auswahl.

So scheint es zunächst, ja.

Dravere schrieb:

Aber auch wenn die Auswahl schlecht wäre, dann ist es halt eben wie mit einer Funktion, welche einen schlechten Namen hat.

Nein, Operatorüberladungen können viel subtilere Probleme verursachen. Das Lieblingsbeispiel von +-fricky ist, wenn ich mich recht erinnere, die Operatorpräzedenz. Das Problem hätte man einfach umgehen können, indem man anstelle der Überladung von << eine Funktion verwendet hätte:

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

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

Aber ich mache den Designern der Stream-Bibliothek keinen Vorwurf daraus. Hinterher ist man immer klüger, und damals war das alles noch neu und toll. Aber all diese Schwachpunkte sind Indizien, daß man sie heutzutage meiden sollte.

Dravere schrieb:

Wieso habe ich überhaupt darauf geantwortet? Wahrscheinlich weil ich mich nicht mehr beherrschen konnte, ich rege mich immer so auf

Es scheint, als hätte mein Einwurf bezweckt, was ich wollte

Edit:

Dravere schrieb:

Aber deswegen ruft auch niemand, dass man Funktionen abschaffen soll ...

Damit wir uns verstehen: ich befürworte das Sprachmittel der Operatorenüberladung ausdrücklich. Jedoch halte ich die Verwendung in den C++-Streams für unangemessen.

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