Ist es sinnvoll heute noch C++ anzufangen?

Tyrdal

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen.

Nein, es ist eine Technik um Resourcenverwaltung handhabbar zu machen. Speicher ist nur eine Resource von vielen. Wenn du aber unbedingt einen GC haben willst dann kannste den in C++ dazulinken und gut ist, in Sprachen ohne Destruktur ist das Aufräumen von Nichtspeicherresourcen dagen ordentlich mühsam und meist nicht so einfach nachzurüsten.

audacia

+fricky schrieb:

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen. würdest du einer sprache mit GC RAII aufdrücken, dann würdest du sie in die programmierer-steinzeit zurückbefördern. ich glaube, das würden die meisten benutzer einer solchen sprache dir nicht verzeihen.

Die C#-Benutzer scheinen zumindest mit dem using-Statement nicht unzufrieden zu sein, und daß in Delphi nun typsichere Smart-Pointer möglich sind, wird auch eher positiv aufgenommen

Tyrdal schrieb:

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen.

Nein, es ist eine Technik um Resourcenverwaltung handhabbar zu machen. Speicher ist nur eine Resource von vielen.

So ist es. Ohne RAII muß man ständig try-finally benutzen, ganz egal, ob für einen Speicherblock, einen Graphikkontext oder einen Dateistream.

knivil

Also Java vs. C++:
Hier jemand sehr bekanntes der gewissen Sachen wie Operatorueberladung, Stack und "Generics" fuer Java fordert: Growing a language

Tyrdal schrieb:

RAII ist zu 99% eine reine C++ technik, ein hilfsmittel, das eingesetzt wird, hauptsächlich um manuelle speicherverwaltung halbwegs erträglich zu machen.

Nein, es ist eine Technik um Resourcenverwaltung handhabbar zu machen.

sagen wir mal: es wird auch dafür benutzt. aber wie begegnet man mit RAII dem problem, wenn ein nicht-trivialer destruktor scheitert (was in der realität oft vorkommen kann, angenommen es gelingt nicht, eine TCP-verbindung zu schliessen, es kommt eine negative rückmeldung bei irgendeiner aktion, oder sowas)?

knivil schrieb:

Also Java vs. C++:
Hier jemand sehr bekanntes der gewissen Sachen wie Operatorueberladung, Stack und "Generics" fuer Java fordert:

der typ ist mathematiker. kein wunder also, dass er sowas wie op-überladung liebt, damit er sich operatoren für klassen für matrizen, polarkoordinaten, komplexe zahlen u.ä. basteln kann. Java ist aber eigentlich nicht auf mathe spezialisiert, sondern soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

tntnet

+fricky schrieb:

der typ ist mathematiker. kein wunder also, dass er sowas wie op-überladung liebt, damit er sich operatoren für klassen für matrizen, polarkoordinaten, komplexe zahlen u.ä. basteln kann. Java ist aber eigentlich nicht auf mathe spezialisiert, sondern soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

Endlich mal ein wahres Wort von Dir. Java ist nicht für alles geeignet. Es ist eine Anfängersprache mit eingeschränkten Funktionsumfang. Dagegen ist C++ eine universelle Programmiersprache, womit Profis ihre Arbeit erledigen können.

knivil

Bloed, dass dieser jemand fuer Sun an Java arbeitete. Auch ist Operatorueberladung nicht der einzige Knackpunkt. Es nur fuer Matheliebhaber als sinnvoll zu erachten, ist etwas ... kurzsichtig. Auch die riesige Klassenbibliothek wuerde er gern gern vom Rest trennen.

Java ist aber eigentlich nicht auf mathe spezialisiert,

Braucht es auch gar nicht, C++ ist auch nicht auf Mathe spezialisiert.

soll eine einfache sprache sein, die jeder leicht lernen und schnell was nützliches damit machen kann.

Da man Java nur mit Klassenbibliothek bekommt, zaehle ich sie mal zur Sprache hinzu. Daher ist Java keine einfache Sprache mehr.

mngbd

Ohne RAII muß man ständig try-finally benutzen, ganz egal, ob für einen Speicherblock, einen Graphikkontext oder einen Dateistream.

Und was ist so schlimm daran?
Python z. B. hat dafür ein eigenes Syntax-Element eingeführt, die Implementation verhält sich unter der Haube ähnlich wie ein Konstruktor/Destruktor-Paar, und das ohne daß die Sprache Destruktoren kennen würde.

JustAnotherNoob

Was so ziemlich genau dem angesprochenem using Statement in C# entspricht, oder sehe ich das falsch?

LordJaxom

mngbd schrieb:

Ohne RAII muß man ständig try-finally benutzen, ganz egal, ob für einen Speicherblock, einen Graphikkontext oder einen Dateistream.

Und was ist so schlimm daran?

try oben, finally unten?

Man hat das gleiche Problem, was in Sprachen wie C oft genug dazu führt, dass allokierte Ressourcen nicht (immer) freigegeben werden. Die Anforderung der Ressource und die Freigabe der Ressource sind räumlich voneinander getrennt, damit kann bei Anpassung des einen die Anpassung des anderen leicht vergessen werden.

Wenn doch der finally-Block wenigstens oben stehen würde..

FileStream fs = new FileStream(...);
finally { fs.close(); }
try {
    ...
} catch (...) {
}

mngbd

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.

audacia

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 / decltype geht 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

knivil

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.

knivil

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.

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.

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