Wofür wird C++ heute noch eingesetzt?

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.

Die vieldiskutierte MFC bringt zum Beispiel genau dieses Verhalten, neue Frameworks wie zum Beispiel Qt nicht unbedingt.

Die Domäne von Java und C# sind vor allem Frontends für Datenbankprojekte, Webzeugs und kleine Tools. Im Bereich Web und kleinen Tools natürlich auch PHP, Python, ruby und co.

C und C++ sind Sprachen die für die Systementwicklung und aufwendige Applikationen gedacht sind. Darum bringen die Sprachen auch die erforderlichen Bausteine dafür mit, zum Beispiel Zeiger. Das setzt natürlich voraus, dass der Programmierer in der Lage ist seine Werkzeuge richtig einzusetzen.

Die Portierbarkeit von C und C++ ist, mit ein wenige Aufwand, deutlich höher als die der als portierbar vermarkteten als C# und Java.

Für Rust fällt mir allerdings kein Projekt ein.

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

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 immer so großartig in C# und Java? Es kommen ein paar Sprachfeatures dazu, das Framework bekommt ein paar neue Funktionen und eine neue Versionsnummer. Bei C++ verhält sich es ähnlich (nur sind die Zyklen kürzer).

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.

volkard

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.

simbad

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?

volkard

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.

cooky451

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?

volkard

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

volkard

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.

Swordfish

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.

Marthog

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.

volkard

Reden wir jetzt von C?

Mechanics

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.