Wofür wird C++ heute noch eingesetzt?
-
LOLAlter schrieb:
volkard schrieb:
Wir hatten Dir doch erklärt, daß man in C++ keine Speicherfehler hat.
#include <iostream> #include <vector> #include <string> using namespace std; int main() { vector<string> v; v.push_back("Hello"); string& x = v[0]; v.push_back("world"); cout << x; }
C++ ist voll von Speicherfehlerfallen.
Kommt in der Praxis nicht vor. Kein Bedarf, was dran zu ändern.
-
CoffeeToGo schrieb:
simbad schrieb:
Auch rust benutzt dynamisches memory und fällt damit als alternative aus.
Wie kommst du denn da jetzt drauf
? In Rust lässt sich alles statisch anlegen, genauso wie in C und C++.
O.K. schlecht formuliert.
-
Bin letzte Woche in C++ über einen dangling Pointer (Iterator) gestolpert. Hatte zwei std::list und verschiebte ein Element in den anderen Container. Den Vorgang musste ich an eine andere Stelle verschieben, das Problem was dadurch entstand war, dass der Iterator danach verwendet wurde, aber auf das nicht mehr vorhandene Element in der ersten Liste zeigte. Das ganze erzeugte seltsame Effekte und zum Glück auch irgendwann einen SEGFAULT. Das ganze ist natürlich meine Schuld
. Habe noch nicht so viel Erfahrung in C++ sammeln können.
Interessant wäre jetzt ob mich Rust vor diesem Fehler bewahrt hätte, wäre das Ownership-System angesprungen und hätte der Compiler den Übersetzungsvorgang verweigert?
-
CoffeeToGo schrieb:
Hatte zwei std::list und verschiebte ein Element in den anderen Container. Den Vorgang musste ich an eine andere Stelle verschieben,
Ah, das alte DuBistTot-Problem vielleicht?
void Monster::move(){ //tuwas, //evtl erzeuge neue Monster. //und evtl stirb if(...) theMonsterList.remove(this);//geht nicht, weil der andere gerade durch die liste läuft }
Ja, da habe ich auch gerne das Löschen verschiebt. Aber nicht, indem ich mir Zeiger merkte, sondern indem ich tote Monster einfach schwarz anmalte und irgendwann bei Gelegenheit schwarze Monster löschte.
-
volkard schrieb:
LOLAlter schrieb:
volkard schrieb:
Wir hatten Dir doch erklärt, daß man in C++ keine Speicherfehler hat.
#include <iostream> #include <vector> #include <string> using namespace std; int main() { vector<string> v; v.push_back("Hello"); string& x = v[0]; v.push_back("world"); cout << x; }
C++ ist voll von Speicherfehlerfallen.
Kommt in der Praxis nicht vor. Kein Bedarf, was dran zu ändern.
Na ja... also so würde ich das jetzt nicht sagen.
-
LOLAlter schrieb:
volkard schrieb:
Wir hatten Dir doch erklärt, daß man in C++ keine Speicherfehler hat.
#include <iostream> #include <vector> #include <string> using namespace std; int main() { vector<string> v; v.push_back("Hello"); string& x = v[0]; v.push_back("world"); cout << x; }
C++ ist voll von Speicherfehlerfallen.
Wo ist da der Fehler?
-
push_back kann auslösen, daß der container wächst und alle elemete einen neuen speicherplatz kriegen. zeiger auf vector-elemente merkt man sich besser nicht.
-
volkard schrieb:
CoffeeToGo schrieb:
Hatte zwei std::list und verschiebte ein Element in den anderen Container. Den Vorgang musste ich an eine andere Stelle verschieben,
Ah, das alte DuBistTot-Problem vielleicht?
void Monster::move(){ //tuwas, //evtl erzeuge neue Monster. //und evtl stirb if(...) theMonsterList.remove(this);//geht nicht, weil der andere gerade durch die liste läuft }
Ja, da habe ich auch gerne das Löschen verschiebt. Aber nicht, indem ich mir Zeiger merkte, sondern indem ich tote Monster einfach schwarz anmalte und irgendwann bei Gelegenheit schwarze Monster löschte.
So ähnlich. Hier ein Beispiel:
auto iter = firstList.begin(); secList.push_back(*iter); firstList.erase(iter); iter = secList.end() -1; //diese Zeile fehlte (*iter).foo()
-
Rustiger schrieb:
Man will keine Speicherfehler mehr. Sie sind aber in der Lage Aufgaben die C++ zugesprochen wurden zu meistern. Das ist neu und macht den ewig Gestrigen natürlich Angst, weil ihre Sprachwahl wohl möglich nicht mehr die beste sein wird.
Du erteilst deinen Argumenten mehr Gewicht, wenn du uns beleidigst und uns als ewig gestrige abstempelst. Weiter so!
-
Dean schrieb:
C++ kommt da zum Einsatz wo es erforderlich ist, dass die Sprache über Jahre hinweg konsistent bleibt.
Gerade Sprachen wie Python, C# , Java und co. befinden sich in ständiger Veränderung. Bei großen Projekten kann keiner den Sprung von Python 2.x zu 3.x oder ähnliches gebrauchen.
Was ändert sich denn bitte bei Java oder .NET? Es wird gerade dort viel Wert darauf gelegt und Arbeit darauf verwandt, sicherzustellen, daß z.B. auch 10 Jahre alte Java Programme auf einer heutigen VM noch einwandfrei laufen. Dein Vergleich von Java und .NET mit irgendwelchen Skriptsprachen ist also absoluter Unfug.
-
Old Europe schrieb:
Rustiger schrieb:
Man will keine Speicherfehler mehr. Sie sind aber in der Lage Aufgaben die C++ zugesprochen wurden zu meistern. Das ist neu und macht den ewig Gestrigen natürlich Angst, weil ihre Sprachwahl wohl möglich nicht mehr die beste sein wird.
Du erteilst deinen Argumenten mehr Gewicht, wenn du uns beleidigst und uns als ewig gestrige abstempelst. Weiter so!
Ich kenn zwar Rust nicht, aber ich denke auch, man muss mit der Zeit gehen, sonst muss man irgendwann mit der Zeit gehen. Die Zeit von C++ (wenn es denn jemals eine gab?) waren die 90'er. Sicher gibt es noch genug Legacy Produkte, die gepflegt werden wollen, genauso wie es ja auch noch COBOL Anwendungen in der Wildnis gibt, aber wenn einige hier schreiben, C++ macht bald ein Comeback, dann ist das doch wohl eher das Wunschdenken eines ewig Gestrigen...
-
Das rumhacken der Rust-Fanboys auf angeblichen Speicherzugriffsfehlern ist ebenso doof wie damals das Rumhacken der Java-Fanboys auf angeblichen Speicherlöchern, sie es damals ebensowenig gab.
-
Aber mit Rust gibts doch noch weniger
-
Swordfish schrieb:
Aber mit Rust gibts doch noch weniger
Ja, typisch. Die wollen einem weniger für mehr verkaufen. Ganz schlechtes Preis/Leistungsverhältnis.
-
volkard schrieb:
Das rumhacken der Rust-Fanboys auf angeblichen Speicherzugriffsfehlern ist ebenso doof wie damals das Rumhacken der Java-Fanboys auf angeblichen Speicherlöchern, sie es damals ebensowenig gab.
Es ist dennoch bei grossen Projekten, insbesondere historisch gewachsenen das Problem, dass man an vielen Stellen nicht genau weiss, wann man den Speicher nun freigeben soll und dadurch in seltenen Faellen Use-After-Free bekommt. Als Beispiel hat einer von Rust-Team ne Audiolibrary von Firefox gebracht, in der es 18 sicherheitskritische Luecken gab und alles Buffer overflow oer Use-After-Free. Keine davon haette der Rustcompiler zugelassen, solange man keinen Murks mit unsafe-Bloecken macht.
-
Reden wir jetzt von C?
-
Warum muss alles immer zu einer Rust Diskussion ausarten? Warten wir doch einfach paar Jahre ab, dann ist Rust endgültig in die Vergessenheit geraten und es gibt keinen Grund mehr, das bei jeder passenden und unpassenden Gelegenheit zu erwähnen.
Ich glaube, grad die komplexen Fälle in C++, wo es tatsächlich noch Speicherprobleme geben kann, wären in Rust genauso problematisch. Natürlich kann man mit dem Borrow System paar einfache Fälle abfangen. Aber bei allem, was etwas komplexer ist, wird der Programmierer sagen, ähm nein, das will ich aber so haben und es ist auch richtig so, und unsafe davor schreiben.
-
Ich kann mich an viele Threads hier erinnern, wo bei Probleme mit C-Programmen geraten wurde doch lieber C++ einzusetzen. Nun ist ein neuer Mitspieler der Systemsprachen an Bord und für Firmen wie Mozilla lautet dann der Rat bei C++-Problemen lieber Rust zu verwenden. Nur durch die Unzulänglichkeiten von C++ ist Rust erst geboren worden.
-
Das spielt keine Rolle. Kaum jemand hier ist ein blinder C++ Jünger. Es ist einfach sehr sehr unwahrscheinlich, dass sich Rust durchsetzt, von dem her ist es einfach nur nervig, ständig damit konfrontiert zu werden. Wenn das in zehn Jahren gewisse Marktanteile hat, können wir wieder drüber reden. Wenn das in zwei Jahren komplett vergessen ist, wäre es Zeitverschwendung, jetzt ständig darauf eingehen zu müssen.
Und mittlerweile empfinde ich das in der Tat als lästig. Mir war Rust egal, hat mich persönlich nicht interessiert, hat mich aber auch nicht gestört und ich habs eher wohlwollend beobachtet. Mittlerweile bin ich davon aber einfach nur entnervt und sollte es irgendwann zur Diskussion stehen, werde ich mich sicher dagegen aussprechen.
-
Es kann nur einen Nachfolger von C++ geben und das ist (C++)++.