Wofür wird C++ heute noch eingesetzt?

Heartbleed hätte es mit Rust gar nicht geben können, denn das war wohl eine ganz kleine Stelle an der ein Speicherfehler provoziert wurde und die halt übersehen wurde.

NewHope schrieb:

Heartbleed hätte es mit Rust gar nicht geben können, denn das war wohl eine ganz kleine Stelle an der ein Speicherfehler provoziert wurde und die halt übersehen wurde.

OpenSSL ist in C geschrieben also kein gutes Beispiel für Speicherfehler in C++ Projekten.

Jodocus

OpenSSL ist ja auch in C programmiert worden.

Hallo NewHope!
Nur rein aus Interesse:
Unter wievielen Namen hast Du eigentlich in den letzten zwei Monaten hier gepostet? Und wie oft hast Du gesagt, dass Dir die C und C++ Fanboys von c-plusplus.net (sic!) so auf den Sack gingen, dass Du nicht mehr posten würdest?

@Offtopic:
Ich bin hier seit 2006 aktiv und wie viele Aliase und vor allem welche ich verwende werde ich dir nicht erzählen. Ich kann dir nur eines sagen, die meisten Posts von Unregistrierten hier sind nicht von mir.

NewHope schrieb:

@Offtopic:
Ich bin hier seit 2006 aktiv und wie viele Aliase und vor allem welche ich verwende werde ich dir nicht erzählen. Ich kann dir nur eines sagen, die meisten Posts von Unregistrierten hier sind nicht von mir.

Dann ist das eine Verwechslung.
Und natürlich gehen mich Deine Aliasnamen nix an.

Nach 60 Tagen Dauergetrolle gegen C und C++, kann ich es nicht mehr hören und hab zielsicher den falschen angeraunzt...
Mea culpa.

Ich gebe nur das wieder, was ich aus den Rust-Beiträgen, den Videos und dem Ausprobieren kennen gelernt habe. Das ist aber kein Getrolle, denn Rust ist wegen der Unzulänglichkeiten von C und C++ entwickelt worden und will in dessen Teichen auch fischen. Es will sogar ins Web, wenn man sich Rust-Projekte wie https://www.skylight.io/ anschaut. Ob davon was gelingt weiß ich auch nicht.

Wenn alles, was die Schwächen von C++ aufzeigt und die Stärken der anderen Sprachen erklärt, Getrolle ist, dann soll man das gleich in der Forenüberschrift so schreiben und verbieten. Das wäre dann zwar Zensur vom feinsten, aber das kennt man ja aus anderen Bereichen, wie der Politik, auch so. Wenn dort keine Gegenargumente zustanden kommen, dann wird versucht zu diskreditieren. So ein Muster lässt sich hier auch bei einigen erkennen.

Ich persönlich habe mich für Rust begeistern können und bin der Meinung dass es genau das ist was die IT ein Stück weit sicherer machen kann. Ich setzte da derzeit alle Energie rein. Aufspringen wenn sich was etabliert hat, kann ja jeder. Das ist wie Bayern-Fan sein. Es muss aber auch Leute gebe die eine Technologie ausprobieren und auch an den Mann bringen, wenn noch keiner sie für voll nimmt. Ohne solche Leute würde es nie was Neues geben was Erfolg hat.

Ethon

Funktionale Programmiersprachen machen die IT noch sicherer. Akzeptiere mal die Unzulänglichkeiten von Rust.

NewHope schrieb:

blablabla

Ahh.
Hab' ich mich doch nicht geirrt.

Um also auf mein ursprüngliches Anliegen zurückzukommen: Bleib bitte bei einem Thema bei einem Alias. Das irritiert sonst.

Ethon schrieb:

Funktionale Programmiersprachen machen die IT noch sicherer. Akzeptiere mal die Unzulänglichkeiten von Rust.

Ich habe nie geschrieben, dass Rust keine Unzulänglichkeiten hat. Es kann nur Sachen garantieren die C und C++ nicht kann und die für die Sicherheit extrem wichtig sind. Und ja, funktionale Programmiersprache bringen einem praktische frei Haus die Korrektheit einer Funktion, das ist auch eine feine Sache.

derFer

Nur eine Anmerkung:
Funktionale Programmiersprachen bringen nicht 100% sicherheit:
Was ist mit Fehlern im Compiler?
Und selbst wenn das nicht:
Sie haben nur den Vorteil das man sie mathematisch beweisen kann (die korrektheit), aber das kostet einiges! Ich würde sogar mutmaßen das die Prüfung genau so viel kostet wie die Entwicklung.

C/++ ist auch korrekt, solange die Compiler Implementierung ok ist und der Programmierer keinen Müll baut.

(Kleines Beispiel zu oberen: Die Haskel IDE Leksah ist in Haskell geschrieben -> Müsste ja fehlerfrei sein.
Aber ich habe selten eine IDE gesehen die so häufig abschmiert).

Also alles eine Frage des Programmierers.
Aber das ist auch alles OT...

Es geht und ging hier nie um 100% Vermeidung von allen Fehlern. Es geht um die 100% Vermeidung von bestimmten SPEICHERFEHLERN! Man kann die auch in C und C++ vermeiden, aber das hängt vom Können des Programmierers ab. Bei Rust hängt es NIE vom Können des Programmierers ab, der Compiler macht das. Genau wie der Compiler bei C++ bestimmte Fehler zur Typensicherheit einem abnimmt, die in C durch viel void* Gedöns auftreten KÖNNEN.

Nun ist es so, dass mit komplexeren Projekten die Wahrscheinlichkeit steigt, in C oder auch C++ Speicherfehlern zu verursachen. In Rust ist es egal wie komplex das Projekt wird oder wie viele Leute daran arbeiten und es ist auch egal wie gut die sind. Es kann KEINE Speicherfehler dieser Art geben, die Sprache wurde extra so konstruiert dass das nicht geht. Und der Hammer ist ja, dass das alles keinen Overhead hat. Ich glaube sogar, es wird so weniger Overhead erzeugt als bei Smartpointern in C++.

Viele verstehen hier nicht einmal die Grundlagen von Rust und warum Sachen da so funktionieren wie sie funktionieren. Dabei ist die Speichersicherheit nur eins der tollen Features. Darauf aufbauend ist die Sprache wie gemacht für Multithreading, was auch wieder Teil der Sprache ist und auch hier kann ein KEINE Data Races geben, so wie in C++.

Schaut euch den Webcast von OReilly an, da wird auch einiges zu Speichersicherheit erzählt. Jim Blandy erklärt da viele Seiten von Rust mit Beispielen.
http://www.oreilly.com/pub/e/3291

Jim Blandy works for Mozilla on Firefox's tools for web developers. He is a committer to the SpiderMonkey JavaScript engine, and has been a maintainer of GNU Emacs, GNU Guile, and GDB. He is one of the original designers of the Subversion version control system

Hier ein Video wo es nur um die Speichersicherheit geht:
https://www.youtube.com/watch?v=9wOzjbgRoNU

Hier eins über C++, D, Rust und Go diskutiert wird, mit dabei Bjarne Stroustrup und Andrei Alexandrescu:
https://www.youtube.com/watch?v=BBbv1ej0fFo

Es ist sehr mühsam eine alternative Sprache vorzustellen, wenn selbst die bewiesenen Grundlagen dieser Sprache nicht akzeptiert werden. Leider ist das Forum hier das einzige deutsche, was sich auch intensiv mit der Systemprogrammierung beschäftigt. Leider ist es sehr C++ lastig, was ja klar ist, da bis jetzt ja auch C++ die einzige Systemsprache war für größere Projekte. Tja, das ist jetzt vorbei. Selbst hier wird C++ in Zukunft was vom Kuchen abgeben müssen, wenn nicht bei Rust oder Go dann bei einem der Nachfolger. Der Stein der modernen Systemsprachen ist ins Rollen gekommen und nimmt fahrt auf.

SLx64

NewHope schrieb:

Es ist sehr mühsam eine alternative Sprache vorzustellen, wenn selbst die bewiesenen Grundlagen dieser Sprache nicht akzeptiert werden.

Niemand behauptet, dass Rust schlecht sei aber dieses ständige generve hier im Forum, dass es das Maß aller Dinge wäre und jeder sofort umsteigen müsste, verringert mMn das Interesse extrem. Rust hat schöne neue Sachen aber es ist weder ausgereift, noch gibt es ausreichend Bibliotheken. Momentan kann man Rust eher beobachten und sich das ganze etwas genauer angucken aber effektiv damit arbeiten und große Projekte erstellen ist momentan eher kontraproduktiv.

NewHope schrieb:

Leider ist das Forum hier das einzige deutsche, was sich auch intensiv mit der Systemprogrammierung beschäftigt. Leider ist es sehr C++ lastig,

Es ist auch ein C++ Forum - wie kann man sich darüber wundern, dass es C++ lastig ist?

simbad

SLx64 schrieb:

Es ist auch ein C++ Forum - wie kann man sich darüber wundern, dass es C++ lastig ist?

RHBaum

Rust hat schöne neue Sachen aber es ist weder ausgereift, noch gibt es ausreichend Bibliotheken.

Genau ....
Dazu kommt noch, das nicht nur das vorhandensein einer Biblio ne Rolle spielt, sondern auch die Lizenz zu. Und nicht nur die RUST Lib, sondern auch die drunter liegende C Lib.

Grad in den Bereichen wo heut C++ noch ne Rolle spielt, ist dieses Thema nicht unerheblich.
Geht schon bei der GUI los, GTK und wxWidgets sind damals bei uns (vor 3 Jahren) aus "Lizenzrechtlichen Gründen" abgelehnt wurden. Dann wirds recht dünn für GUI's auf dem "beliebtesten Desktop OS im kommerziellen Umfeld"

Ciao ...

nman

RHBaum schrieb:

Geht schon bei der GUI los, GTK und wxWidgets sind damals bei uns (vor 3 Jahren) aus "Lizenzrechtlichen Gründen" abgelehnt wurden.

Dann hat damals aber vmtl. auch irgendjemand die LGPL missverstanden. Zumal die wxWidgets-Lizenz ja nochmal loser als die LGPL ist.

Unter welcher Lizenz stehen denn die Bibliotheken?
Rust selber ja unter der Apache / MIT da sehe ich keine Probleme.
Wobei ich nicht ganz verstehe warum man eine Sprache nicht public domain macht. Was hat man denn davon das noch einzuschränken?

Marc-O

Hallo

Phil_ schrieb:

...
@Marc-O Dein Problem mit Diensten erschließt sich mir jetzt nicht. Wenn du da Schwierigkeiten hattest, liegt das doch wahrscheinlich eher an deiner Unvertrautheit (?) mit dem .NET Framework?

Nein das liegt eher daran, das bei Diensten meist darum geht Bits herum zu schubsen, Kommunikation mit SPSen zu unterhalten oder darum Dateien zu lesen die ein komplett eigenständigen Bit-basiertes Aufbau haben. Ja ich hab es auch via C# implementiert, ist aber bei weitem nicht so angenehm und der Speicherverbrauch schreckt mich immer wieder ab. (C++ ca. 10MB, C# mit nicht mal der Hälfte der Implementierung und benötigt ca. 50MB).

Und wegen Unvertrautheit, ich glaube nachdem ich jeden C# Versionswechsel mit machen durfte, sollte mir das .NET Framework gut genug bekannt sein.

Aber wenn wir schon bei Rust sind, wie schaut es dort eigentlich mit Ring-Verkettungen aus, alla Vater hat Kinder, die wiederum ihren Vater kennen? (Hab leider kein Beispiel in Rust dazu gefunden, geschweige in der Doku was dazu finden können) Wie wird das in Rust abgehandelt und erkennt der Compiler diese Problematik?

(Ist eins der typischen Probleme in C#, wo es ja eigentlich auch heißt, das Speicherlecks nicht mehr auftreten könnten)

Und nochmal zum Thema, in vielen großen Altlastsystem, wird wie schon viele vorher gesagt haben, C++ nicht einfach ausgetauscht. Können sich die wenigsten einfach leisten. Ist bei uns nicht anders, wir pflegen aktuell sogar noch VB-Code.

MfG MarcO

rust|cppEgal schrieb:

Unter welcher Lizenz stehen denn die Bibliotheken?
Rust selber ja unter der Apache / MIT da sehe ich keine Probleme.
Wobei ich nicht ganz verstehe warum man eine Sprache nicht public domain macht. Was hat man denn davon das noch einzuschränken?

Damit Microsoft die Sprache nimmt und zum Standard inkompatibel macht, so wie bei Java geschehen? Nö! Deswegen nimmt man Lizenzen die den Standard zusammenhalten.