Ist es sinnvoll heute noch C++ anzufangen?
-
try oben, finally unten?
Ja, das ist schlecht.
Ich sehe da aber nur ein syntaktisches Problem, und deshalb keinen Grund, die Interpretation der Sprache zu verändern.
In Lisp würde ich mit einem Makro auskommen, neue Semantik könnte ich mir sparen.
-
mngbd schrieb:
In Lisp würde ich mit einem Makro auskommen, neue Semantik könnte ich mir sparen.
Das ist wunderbar, hilft aber in Java und C# herzlich wenig
In C++ mit
typeof/decltypegeht es übrigens auch mit einem Makro:UCL_SAFEGUARD (MyListView->Items, object->BeginUpdate (), object->EndUpdate ());
-
tntnet schrieb:
Endlich mal ein wahres Wort von Dir. Java ist nicht für alles geeignet. Es ist eine Anfängersprache mit eingeschränkten Funktionsumfang.
was gegenteiliges hab' ich doch nie behauptet. nur nicht, dass Java ein reine anfängersprache ist. auch fortgeschrittene kommen mit Java ziemlich weit.
tntnet schrieb:
Dagegen ist C++ eine universelle Programmiersprache, womit Profis ihre Arbeit erledigen können.
aber diese mutmaßlichen 'profis' machen sich damit oft das leben unnötig schwer. dass mit C++ alles irgendwie machbar ist, bedeutet lange nicht, dass C++ für alles die beste wahl ist.
knivil schrieb:
Es [op-overloading] nur fuer Matheliebhaber als sinnvoll zu erachten, ist etwas ... kurzsichtig.
vielleicht. aber noch kurzsichtiger wäre es, mit op-overloading eine relativ benutzerfreundliche und einfache sprache zu vergiften, und damit kuriositäten tür und tor zu öffnen (wie mehrfachverwendung von operatoren, wie z.b. in c++, wo << ein shift- wie auch ein streaminput-op ist).
knivil schrieb:
Da man Java nur mit Klassenbibliothek bekommt, zaehle ich sie mal zur Sprache hinzu. Daher ist Java keine einfache Sprache mehr.
die klassenlib kann aber sehr minimal sein, wie dort z.b: http://www.harbaum.org/till/nanovm/index.shtml
-
What the NanoVM is and what it isn't ...It is not a full featured Java VM and it will never be.
kuriositäten tür und tor zu öffnen (wie mehrfachverwendung von operatoren, wie z.b. in c++, wo << ein shift- wie auch ein streaminput-op ist
Ich kann noch mehr Verwirrung mit Methodennamen erreichen. Das ist kein Argument.
-
knivil schrieb:
What the NanoVM is and what it isn't ...It is not a full featured Java VM and it will never be.
klar, ist ja auch für schwachbrüstige AVRs. die nano-VM hat noch nicht mal 'nen GC, geschweige denn einen heap. nur ein paar fest eingebaute final-klassen um so'n paar roboter-modelle zu steuern. Java ist nunmal sehr bequem für hobbybastler, die zwar handwerklich geschickt sind, aber vom programmieren kaum ahnung haben. AVRs werden auch gern in BASIC programmiert (allerdings läuft dann keine VM, sondern der compiler erzeugt echten maschinencode). die meisten professionellen anwender programmieren AVRs u.ä. aber in C.
knivil schrieb:
kuriositäten tür und tor zu öffnen (wie mehrfachverwendung von operatoren, wie z.b. in c++, wo << ein shift- wie auch ein streaminput-op ist
Ich kann noch mehr Verwirrung mit Methodennamen erreichen.
aber das muss schon in böser absicht geschehen. mit operatorüberladung schaffst du, ohne viel zutun, verwirrung bei jedem, der nicht dieselben gedankengänge hat, wie du.
-
+fricky schrieb:
die meisten professionellen anwender programmieren AVRs u.ä. aber in C.
nachtrag: ...und natürlich in assembler. in C++ jedenfalls nicht.
-
die nano-VM hat noch nicht mal 'nen GC, geschweige denn einen heap
Und darf sich trotzdem Java nennen? Ich verstehe aber immer noch nicht, was dein Beispiel mir sagen soll.
Ein einfacher Methodenname ist z.B. "next". Was er bedeutet, haengt ganz allein vom Objekt und dessen Typ ab. 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. Und schliesslich: Warum hat Java ueberhaupt Operatoren?
nachtrag: ...und natürlich in assembler. in C++ jedenfalls nicht.
Es gibt bestimmt auch genug Beispiele fuer C++ im embedded Bereich.
-
+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
-
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.
-
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.
-
Dravere schrieb:
... VERBIETEN!"
hei dravere - wusste gar nicht das du politiker bist #gg
-
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,
:pGrüssli
-
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.
-
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.
-
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
-
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.
-
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);
-
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.
-
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.
-
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
