C
h^2
hat ne Keule +1
Ach gottchen, da gibt er selber zu hauptsächlich C zu machen und will dann wissen was für C++ besser ist. "Don't pay for what you don't use", dafür nutzt man C++, wenn er meint, dass man für range checks nicht zahlt, hat er keine Ahnung. Wenn performance nicht entscheidend ist (was es ganz oft nicht ist!!!), dann kann er doch python oder sowas nehmen.
rubricanis
Homo ludens
Na ja, übertreib mal nicht, das sind dann ganz andere Hausnummern als range checks oder nicht...
Mal gibt es Gründe den Bereich zu ckecken, mal nicht. Wichtig sind allerdings die defaults, da man sich daran meistens hält. Und diesbezgl. ist das Verhalten von [ ] etwas unglücklich.
h^2
hat ne Keule +1
> Und diesbezgl. ist das Verhalten von [ ] etwas unglücklich.
Naja, es gibt ganze Arbeitsgruppen, die sich mit undefined behaviour in C++ beschäftigen, das ist doch nicht nur der operator[]. Und bei irgendeinem neuen Typen zufällig anzufangen das Verhalten des operator[] jetzt anders zu machen als bei allen anderen würde die Leute doch auch nur noch mehr verwirren. Ich würde mich allerdings dafür einsetzen, dass die STL mehr asserts im Debug-Modus verwendet, das machen viele so und das kostet im Release-Modus definitiv nix.
Naja, es gibt ganze Arbeitsgruppen, die sich mit undefined behaviour in C++ beschäftigen, das ist doch nicht nur der operator[]. Und bei irgendeinem neuen Typen zufällig anzufangen das Verhalten des operator[] jetzt anders zu machen als bei allen anderen würde die Leute doch auch nur noch mehr verwirren. Ich würde mich allerdings dafür einsetzen, dass die STL mehr asserts im Debug-Modus verwendet, das machen viele so und das kostet im Release-Modus definitiv nix.
rubricanis
Homo ludens
Legacy brings burden!
Ich bin ja nicht unbedingt ein Freund von "alles neu"! Aber irgendwann muss man die Bude ja mal aufräumen. Und wenn das nicht der Fall ist, stolpert man eben über alle möglichen Klamotten die rumliegen. Und je weiter man das dann aufschiebt, umso schlimmer wird es, - was bei Arbeitsgruppen das immer sehr, sehr lange dauert!In der Zwischenzeit machen sich solche Sachen wie D und Rust breit und breiter...
C
CrimsonKing
Guest
D macht sich breiter? Wo denn das?
rubricanis
Homo ludens
Hast ja recht!
Aber für Rust stimmt das sicherlich! Aber lassen wir mal besser das Thema C++ vs. Rust.
-Nuke-
Well-Known Member
Wie man es halt persönlich mag bzw. die Möglichkeiten hat. Bei Rust ist es z.B. je nach Aufgabe schwierig den Code schnell zu bekommen. "Der Compiler macht das schon" ist auch so ein Märchen was schon seit Jahren erzählt wird.
Da hat man dann auch die Wahl zwischen "einfach so lassen" oder eben "unsafe" drum rum zu packen und selbst zu prüfen. Die Performance schlecht zu lassen ist auch nicht immer eine Option.
Man kann jetzt natürlich auch C++ in die Richtung modifizieren. Aber die Geschichte mit "der Compiler macht das schon" glaube ich weiterhin nicht. Zumindest nicht in allen Fällen.
Da hat man dann auch die Wahl zwischen "einfach so lassen" oder eben "unsafe" drum rum zu packen und selbst zu prüfen. Die Performance schlecht zu lassen ist auch nicht immer eine Option.
Man kann jetzt natürlich auch C++ in die Richtung modifizieren. Aber die Geschichte mit "der Compiler macht das schon" glaube ich weiterhin nicht. Zumindest nicht in allen Fällen.
rubricanis
Homo ludens
Yep! Aber "unsafe" ist dein Freund, auch wenn das nicht im Sinne der Erfinder ist!
Damit verschenkt man sich bestenfalls etwas an Optimierungen.
Die "man muss mal aufräumen"-Fraktion vergisst nur gerne, dass Milliarden oder vielleicht sogar Billionen Zeilen vorhandener Code existieren. Da stecken >30 Jahre Know-How und unvorstellbar viele Mannstunden drin. Aufräumen bedeutet zwangsläufig Rückkompatiblität zu brechen und damit alles wegwerfen oder zumindest überarbeiten zu müssen. Das macht niemand, stattdessen nutzt man dann halt die alte Sprache oder Sprachversion weiter.Legacy brings burden!
C
CrimsonKing
Guest
Na, wer sagt als erster "COBOL!"?
rubricanis
Homo ludens
Mit den gleichen Argumenten läßt man Brücken verrotten, fährt mit Dreckschleudern auf der Straße, pustet den Rauch von Braunkohlen in die Luft und lebt in halb verrotteten Häusern, - zumindest ein Teil des ärmeren Teiles der Bevölkerung. Und sagt nicht, das wäre bei Software anders. Dennis Ritchie hat eine fragwürde Vorrangregelung von Operatoren bei C in der Sprache belassen (ich weiß nicht mehr welche) weil die Sprache damals von 50 (!) Programmieren genutzt wurde die er nicht frustrien wollte. Seit dem werden jede Menge Klammerin in C eingesetzt um auf der sicheren Seite zu sein. Software ist nicht anders, auch die muss gewartet und gepflegt und weiter entwickelt werden. Was es nämlich kostet den Ballast von 50 Jahren einfach so mitzuschleppen wird man kaum beziffern können.
Aufräumen heißt nicht abreißen, sondern sich von überflüssigem und verrottetem Balast befreien und Raum für neues und besseres zu schaffen für das sonst keine Spielräume mehr verbleiben. Ob das Neue dann wirklich besser ist wird sich erst nach einigen Jahren zeigen. Aber selbst wenn sich zeigt dass es Mist ist, wird nach der gleichen Logik einfach weitergemacht weil ja so viele Mannstunden reingesteckt worden sind...
Die Wertschätzung des Überkommenen zeigt sich nicht darin, dass alles bleibt wie es ist, sondern darin dass die Idee der Sache bewahrt, aber historisch gewachsene Fehlentwicklungen korrigiert werden. Evolution ist hier das Stichwort, nicht Revolution. Wenn die aber nicht erfolgt, treten früher oder später ganz neue Arten auf.
Zum Thema Erfahrung: Einer der Vorväter unseres Schulsystems hat im frühen19. Jhd. einmal folgendes gesagt: "Erfahrung, Erfahrung, ich höre immer nur Erfahrung! Was ist denn die 30 jährige Erfahrung eines preußischen Schulmeisters anderes als die Erfahrung von 30 Jahren Schlamperei!? "
Ich hoffe da fühlt sich hier niemand angesprochen! Erfahrung ist wichtig, denn nur durch Erfahrungen können Fehlentwicklungen korrigiert werden. Wenn die Erfahrungen aber wie Beton sind und nicht in einem weiteren Horizont eingebettet, dann wird es problematisch.Das Thema ist kein technisches, sondern zugleich ein menschliches, soziales, wirtschaftliches und politisches Problem, - also unlösbar!
Zuletzt bearbeitet:
-Nuke-
Well-Known Member
Man muss aber auch nicht jedes Thema um drei Ecken in ein politisches wandeln. Zumal es auch überhaupt nicht zum Thema passt, denn wie du siehst wird ja offensichtlich daran gearbeitet Probleme zu beheben. Auch wird schon seit Jahrzehnten daran gearbeitet, dass Compiler auch ohne Sprach-Änderungen sichereren Code ausspucken oder sicherer Ausführen können. Fortify-Source, stack-protector, PIE und ASLR sind dort nur ein paar Stichworte. Ebenso sind es Dinge wie das NX bit und "neu neu neu" pointer authentication auf Hardwareebene.
Letztendlich bringt auch die sicherste Sprache und/oder das sicherste OS nichts, wenn der Entwickler hinterher Mist baut. Das Äquivalent zu Heartbleed bei OpenSSL wäre unter Rust die Nutzung von unsafe + irgend ein grenzdebiler Kram, weil sonst die Performance zu schlecht ist. Man kann auch Sicherheitslücken einbauen, ohne dass es immer gleich ein Buffer-Overflow ist.
Man darf bei dem Thema auch nicht übersehen wie portabel C++ so ist. Rust hat hauptsächlich Support für die x86(_64) Architektur, alles danach ist dann nur noch "it depends". Also nicht, dass es gar nicht läuft, aber es ist entweder ungetestet, nicht unterstützt oder es fehlt irgendwas. Bei C++ wird's schwer was zu finden wo es _nicht_ geht.
Das Thema ist halt wesentlich vielschichtiger als reine Sicherheits-Features. Rust ist auf einem guten Weg, aber halt noch weit davon entfernt C++ ersetzen zu können. Solange muss man damit leben und ggf. einfach C++ verbessern.
Letztendlich bringt auch die sicherste Sprache und/oder das sicherste OS nichts, wenn der Entwickler hinterher Mist baut. Das Äquivalent zu Heartbleed bei OpenSSL wäre unter Rust die Nutzung von unsafe + irgend ein grenzdebiler Kram, weil sonst die Performance zu schlecht ist. Man kann auch Sicherheitslücken einbauen, ohne dass es immer gleich ein Buffer-Overflow ist.
Man darf bei dem Thema auch nicht übersehen wie portabel C++ so ist. Rust hat hauptsächlich Support für die x86(_64) Architektur, alles danach ist dann nur noch "it depends". Also nicht, dass es gar nicht läuft, aber es ist entweder ungetestet, nicht unterstützt oder es fehlt irgendwas. Bei C++ wird's schwer was zu finden wo es _nicht_ geht.
Das Thema ist halt wesentlich vielschichtiger als reine Sicherheits-Features. Rust ist auf einem guten Weg, aber halt noch weit davon entfernt C++ ersetzen zu können. Solange muss man damit leben und ggf. einfach C++ verbessern.
rubricanis
Homo ludens
Klein!
Aber der Blick aus der Ferne läßt manches erkennen was aus der Nähe nicht so ohne weiteres erkennbar ist. Und wo kämen wir hin wenn nur noch die Auffassung von Insidern gelten würden: Dann stimmt nämlich die Welt - bis auf Marginalien - immer! Im übrigen: Das sind so rhetorische Argumente wenn man den zu den sachlichen nichts ernsthaftes sagen will oder kann...
rubricanis
Homo ludens
Das sehe ich auch so. Was die C/C++ Welt von Rust lernen kann ist u.A. das tooling, cargo und so. Was ich mir persönlich wünschen würde ist ein besseres C, das ist C++ nämlich nur sehr bedingt. Aber eher geht ein Kamel durch ein Nadelöhr...
-Nuke-
Well-Known Member
Das sehe ich auch so. Was die C/C++ Welt von Rust lernen kann ist u.A. das tooling, cargo und so. Was ich mir persönlich wünschen würde ist ein besseres C, das ist C++ nämlich nur sehr bedingt. Aber eher geht ein Kamel durch ein Nadelöhr...
Das Problem an C ist nicht unbedingt die Sprache (zumindest nicht mehr als C++), sondern dass die Standard Bibliothek etwas chaotisch ist. Das liegt zum Teil auch daran, dass Microsoft soweit ich weiß immer noch kein C99 und C11 unterstützt. Dazu ist die halbe Standard-Bibliothek unsicher und man sollte "bessere" Varianten nehmen. Zufälliges Beispiel: sprintf (unsicher), snprintf ("sicher" seit C99), sprintf_s (Microsoft C). Natürlich arbeiten snprint und sprint_s auch dezent anders und sind nicht zu 100% austauschbar.
rubricanis
Homo ludens
Stroustrup, zumindest habe ich ihn im ersten Teil seines Buches so verstanden wo er sagt dass man C++ auch als "besseres C" verwenden könne, was er aber für verfehlt hält. Aber die Abstammung ist klar: C und Simula. Seit dem denkt alle Welt - na gut, ein guter Teil - in OOP.
rubricanis
Homo ludens
OK, mit Ausnahmen. Ich stimme da Walter Bright im wesentlichen zu. Natürlich kann man FatPtr auch so oder in einer Biblothek verwenden was ja auch gemacht wird. Aber derartiges in einen Std. und in eine StdLib zu bringen ist eine andere, und bessere Sache. Ein vernünftiges Modul-Konzept, tooling a'la rust und Generics wären auch möglich ohne Rückwärtskombatibilität zu gefährden. Na ja...
Mit c14 habe ich mich übrigens noch nicht befaßt. Bringt das wesentliches?
C
CrimsonKing
Guest
Und dann die von C++ danebenhalten und sich freuen, wie logisch die von C doch strukturiert ist ...
Es gibt kein C14. Der auf C11 folgende C-Standard ist C18.
C++14 ist eigentlich vor allem ein Bugfix, wirklich neue Dinge (u.a. std::filesystem) kamen erst mit C++17.
-Nuke-
Well-Known Member
Und dann die von C++ danebenhalten und sich freuen, wie logisch die von C doch strukturiert ist ...
Letztendlich hat das Problem jede Sprache mit einem bestimmten Alter. Java ist z.B. jetzt auch nicht gerade das Übersichtlichste. Da hat die neue Sprache natürlich den Vorteil, dass man noch zu nichts abwärtskompatibel sein muss. C#/.NET hat auch schon viele Iterationen miterlebt, hier wurden jedoch knallhart Dinge aus dem Standard entfernt. So läuft eine .NET 1 Anwendungen nicht unbedingt auf .NET 2, .NET4 nicht auf dem neuen .NET Core Kram usw. Das sorgt natürlich auch für Frustration unter den Anwendern, hält aber die Sprache und Standard-Lib einigermaßen sauber. Ist aber auch ein Grund warum sich .NET bisher kaum großartig "durchsetzen" konnte. Zumindest im OpenSource Bereich fasst das kaum einer an. ASP.NET hat ein paar mehr Anwender, ansonsten hier und da mal einer.
Andy_m4
Well-Known Member
Mit C++ bin ich ja nie so richtig warm geworden aus verschiedensten Gründen. C lasse ich mir ja noch Gefallen, wenngleich auch das ein wenig ein Kulturschock war, nachdem ich zuvor bei Turbo Pascal war.
C++ ist aber in meinen Augen unnötig Komplex und bietet unnötig viel Fehlerpotential.
Gut. vieles ist sicherlich historisch gewachsen, wie man so schön sagt. Und unter ausschließlicher Verwendung von modernen C++ bekommt man viele Probleme auch in den Griff. Trotzdem bleibt der Lernaufwand relativ hoch. Vor allem in Relation zu dem, was man bekommt.
unsafe ist aber natürlich auch eine legitime Lösung. Immerhin brauch ich ja nur den Teil des Codes als unsafe deklarieren, wo es wirklich drauf ankommt. Der Rest ist dann immer noch "safe".
Ich weiß übrigens gar nicht, warum hier offenbar ganz natürlich davon ausgegangen wird, dass sich nur mit C++ performante Programme schreiben lassen. Insbesondere bei numerischen Kram kommt aus Performance-Gründen gern mal der Programmiersprachenveteran Fortran zum Einsatz.
Sogar Intel selbst bietet ein optimierenden Fortran-Compiler an:
https://software.intel.com/en-us/fortran-compilers
Warum nutzt Du dann einen und schreibst nicht Assembler?
Abgesehen davon täte der ein oder anderen gammligen Bibliothek ein aufräumen mal ganz gut. :-)
Entscheidender ist ja, wie hoch ist die Wahrscheinlichkeit das ich Fehler einbaue. Andere Sprachen kennen ganze Fehlerklassen nicht. Ist logisch, dass man damit dann automatisch tendenziell eher fehlerfreier programmiert.
Die defaults sind also schon eher auf Sicherheit gemünzt.
Die Standardbibliothek ist auch vergleichsweise überschaubar. Sprich, Du kommst bei C++ sehr schnell auf den Boden der Tatsachen.
C++ ist aber in meinen Augen unnötig Komplex und bietet unnötig viel Fehlerpotential.
Gut. vieles ist sicherlich historisch gewachsen, wie man so schön sagt. Und unter ausschließlicher Verwendung von modernen C++ bekommt man viele Probleme auch in den Griff. Trotzdem bleibt der Lernaufwand relativ hoch. Vor allem in Relation zu dem, was man bekommt.
Ich bin Nichtraucher und erlaube trotzdem die Einschätzung, dass die Verringerung des Tabakkonsums sich positiv auf die Gesundheit auswirkt. :-)
Ist korrekt. Aber selbst solche Sachen waren schon bei Turbo Pascal besser gelöst. Da war das nicht etwa irgendwie intransparent implementiert, sondern durch Compilerschalter (entweder global oder im Quelltext).
Genau das ist einer der Probleme. Das es überhaupt so was wie undefined behaviour gibt. Als ob sich da nie jemand ernsthaft Gedanken drum gemacht hätte. Und genauso so fühlt sich C++ an vielen Stellen an.
Oder mehr Hardware draufwerfen. Das ist meist billiger als nem Programmierer Optimierungen vornehmen zu lassen, die dann ggf. noch Sicherheitslücken ins Programm reißen.
unsafe ist aber natürlich auch eine legitime Lösung. Immerhin brauch ich ja nur den Teil des Codes als unsafe deklarieren, wo es wirklich drauf ankommt. Der Rest ist dann immer noch "safe".
Ich weiß übrigens gar nicht, warum hier offenbar ganz natürlich davon ausgegangen wird, dass sich nur mit C++ performante Programme schreiben lassen. Insbesondere bei numerischen Kram kommt aus Performance-Gründen gern mal der Programmiersprachenveteran Fortran zum Einsatz.
Sogar Intel selbst bietet ein optimierenden Fortran-Compiler an:
https://software.intel.com/en-us/fortran-compilers
Warum nutzt Du dann einen und schreibst nicht Assembler?
Ja. Was man aber natürlich machen kann ist für Neu-Projekte entweder auf C++ zu verzichten oder eben genau darauf zu achten, was man nutzt. Und für letzteres gibts ja Codeanalysewerkzeuge die einen dann auch Warnen, wenn irgendwas nicht ganz koscher ist oder ein veraltetes Konstrukt benutzt.
Abgesehen davon täte der ein oder anderen gammligen Bibliothek ein aufräumen mal ganz gut. :-)
Gut. Aber das ist kein Argument, weil Du damit jegliches widerlegen kannst.
Entscheidender ist ja, wie hoch ist die Wahrscheinlichkeit das ich Fehler einbaue. Andere Sprachen kennen ganze Fehlerklassen nicht. Ist logisch, dass man damit dann automatisch tendenziell eher fehlerfreier programmiert.
Der Unterschied ist, unsafe musst Du halt explizit und bewusst setzen. Bei C++ hast Du eher mal Situationen das wenn Du irgendwo etwas vergisst, dass dann Dein Code unsicher ist.
Die defaults sind also schon eher auf Sicherheit gemünzt.
C++ ist so toll portabel, dass Du schon in Probleme kommen kannst, wenn Du GCC statt clang einsetzt (oder umgekehrt).
Die Standardbibliothek ist auch vergleichsweise überschaubar. Sprich, Du kommst bei C++ sehr schnell auf den Boden der Tatsachen.
Warum es das noch nicht gibt, kann mir auch keiner vernünftig erklären. Rusts Unzulänglichkeiten kann man ja immer noch mit dem vergleichsweise jungen Alter entschuldigen. Aber C++ gibts jetzt schon seit Mitte der 80er Jahre und trotzdem fehlen immer noch Basics.
C
CrimsonKing
Guest
Auch "Assembler" braucht 'nen Compiler für die Umwandlung in Maschinencode. Du tippst den Code ja nicht direkt in eine ausführbare Datei rein. (Leute, die ohne Not von Pascal auf C umsteigen, verstehe ich aber nicht (mehr).)
-Nuke-
Well-Known Member
Nicht jedes Performance-Problem lässt sich mit Hardware erschlagen, ganz einfach weil keine unendliche schnelle Hardware existiert. Wenn dein Problem "sicher" in 5min lösbar ist und "unsicher" in 20s, dann diskutiert man das nicht unbedingt einfach weg. Will auch gar nicht behaupten, dass Rust unendlich langsam ist, ist es ja nicht. Ich hab nur schon selbst Projekte gesehen, die in ziemlich große Performance-Probleme gerannt sind und letztendlich "unsafe" die einzige Lösung war. Da ist das Vermeiden von [] in C++ jetzt auch nicht so das Mega-Problem.
Hat niemand behauptet. Das Thema ist halt C++. Du wirst auch vermutlich im Nachwuchs-Markt für Programmierer nur noch wenig Leute finden die Fortran können.
Huh? Darum geht's doch gar nicht. Die Gegenüberstellung ist: Ich erlaube dem Entwickler einen unsicheren Pfad für Performance-Kritische Stellen, oder ich knalle automatisch alles mit Sicherheits-Checks zu und hoffe, dass der Compiler schon selbst erkennt was ohne sowas auskommt. C++ ist "im Standard eher unsicher, geht aber auch sicher", Rust ist "im Standard sicher, optional unsicher" und z.B. Java ist "Im Standard sicher, der Compiler versucht was er kann". Und das Thema ist jetzt C++ quasi in die Richtung der Java-Arbeitsweise zu kriegen.
Niemand hat behauptet, dass C++ (oder sogar C) ein "Write-Once-Compile-Anywhere" ist. Wenn du (mal ins Blaue rein gesponnen) eine Anwendung für die Nintendo Wii U portieren willst, dann hast du mit C++ wesentlich weniger Kopfschmerzen, als wenn du da gerade ein Rust Projekt vor dir hast. Und natürlich ist C++98 portabler als C++17. Genauso ist C89 portabler als C99 und das wiederum portabler als C11.
Wie ich schon gesagt habe, Rust ist auf einem guten Weg. Die "(Standard-)Library", wenn man sie mal so nennen will, füllt sich stetig. Probleme hier und da werden behoben... aber es gibt halt Leute die suchen aktuell eine Lösung für aktuelle Probleme und können nicht warten bis Rust irgendwann mal soweit ist. Und "ich zieh da mal die eine Lib von Github und baue das in mein Produktiv-Code ein" ist für einige Projekte auch ein NoGo.
Das betrifft natürlich nicht alle Projekte und ich bin durchaus dafür neue Projekte in einer Sprache wie Rust zu schreiben, wenn es möglich ist. Es löst aber halt trotzdem nicht alle Probleme.