Ist C++ noch zu retten?



  • @wob sagte in Ist C++ noch zu retten?:

    @Bashar sagte in Ist C++ noch zu retten?:

    Für ein Nicht-Problem.

    Das stimmt einfach nicht. Das ist sogar ein mehrfaches Problem:

    1. du treibst potentielle Entwickler von C++ weg - weil niemand Überraschungen mag. Stell dir Studenten in einem naturwissenschaftlichen Bereich vor, die C++ machen, weil das Framework in C++ ist. Somit ist es häufig die erste Programmiersprache, die gelernt wird. Sehr sehr viele Stunden Fehlersuche werden dadurch verursacht, dass dies nur eine Warnung ist (man sollte Warnung ernst nehmen, bla bla bla, das ist schön und gut, passiert aber eben nicht immer)

    Auch ein Nicht-Problem. Was wollen die alle mit C++? Es gibt soviele andere Programmiersprachen. C++ ist schwer, und es ist erstaunlich, wieviele junge Entwickler trotzdem meinen C++ machen zu müssen. Guck dich doch hier im Forum um ... einer will Webseiten mit C++ auslesen, einer will seine Lagerverwaltung mit C++ machen... es herrscht kein Mangel.

    1. der Code war auch möglicherweise auch vor 25 Jahren falsch. Mein Beispiel ist UB. Toll, der Bug soll bleiben, weil er immer da war?

    Da hatte man 25 Jahre Zeit, die Warnung zu beachten.

    Mir geht es hier aber nicht um den Fall, in dem da tatsächlich ein Bug drin ist, sondern um die sehr viel häufigeren Fälle, in denen es keinen Unterschied macht, die man alle anpassen müsste.

    1. Man hätte ja einführen können, dass das ab C++11, 17, 20, oder was auch immer ein Fehler ist. Den 25 Jahre alten Code könntest du immer noch mit C++98 (wenn überhaupt) übersetzen.

    Wieso ist das Punkt 3 in einem vermeintlichen Argument, dass das ein "mehrfaches Problem" sei? Das ist ein Lösungsvorschlag, und der naheliegendste überhaupt. Natürlich würde ein Verbot sich nur auf einen Standard und alle folgenden auswirken, man kann ja nicht rückwirkend C++98 ändern.



  • Also bei Aggregate-Initializers ist es wohl vom Standard vorgeschrieben dass die Reihenfolge passt. Damit ist jedes Programm "malformed" welches so eine Liste mit falscher Reihenfolge enthält, und jedes "malformed" hat IIRC automatisch UB. Also laut Standard. Laut Compiler wird sich der einfach weigern das zeug überhaupt zu compilieren. Und wenn man es ihm mir irgendwelchen Switches einreden kann es trotzdem zu compilieren, dann wird es dort effektiv sicher auch kein UB geben.
    Strang laut Standard müsste es mMn. aber UB sein.

    @Steffo
    Wenn ihr haufenweise Warnings abdreht bzw. die üblichen -Wall -Wextra nicht aufdreht, dann ... selbst schuld würde ich sagen.



  • @Bashar sagte in Ist C++ noch zu retten?:

    Welches Buch? Den Jahresband von Computing Systems 1989? Was du so im Regal hast... es war jedenfalls kein Zitat aus D&E.

    Dieser Abschnitt (konkret 12.9) findet sich auch im Buch „The Design and Evolution of C++“.

    Nicht wirklich, diese Frage ist da schon längst geklärt.

    Das Buch ist ein Rückblick auf die C++ Entwicklung bis zur ersten ISO Norm. Mit der Norm ist es dann geklärt gewesen. Aber mit Sicherheit nicht beim Erscheinen der ersten Cfront Version.

    Wenn die Reihenfolge unspezifiziert ist, darf man sich nicht auf eine bestimmte Reihenfolge verlassen und die Initialisierung eines Members nicht von einem anderen abhängig machen. Dann ist die Reihenfolge, in der man die Initialisierer angibt, auch egal.

    Das sind zwei Aspekte. Wenn die Reihenfolge unspezifiziert ist, gäbe es zwei Möglichkeiten: man dürfte
    a) in beliebiger Reihenfolge die Initialisierung als Programmierer vornehmen (welche dann die Initialisierungsreihenfolge definiert), oder
    b) der Compilerbauer dürfte die Initialisierung in beliebiger Reihenfolge vornehmen, abweichend vom Programmcode.

    Im Fall von b) darf man dann in der Tat sich nicht auf die Reihenfolge verlassen, weil man dann als Programmierer keinerlei Kontrolle hätte. Nur was spricht gegen a) ?



  • @john-0 sagte in Ist C++ noch zu retten?:

    @Bashar sagte in Ist C++ noch zu retten?:

    Welches Buch? Den Jahresband von Computing Systems 1989? Was du so im Regal hast... es war jedenfalls kein Zitat aus D&E.

    Dieser Abschnitt (konkret 12.9) findet sich auch im Buch „The Design and Evolution of C++“.

    Aha. Und dort ist das ein Plädoyer "dafür die Reihenfolge gar nicht vorzuschreiben"?

    Du brauchst nicht zu antworten. Mich nervt diese "Diskussion".



  • @Bashar sagte in Ist C++ noch zu retten?:

    Auch ein Nicht-Problem. Was wollen die alle mit C++? Es gibt soviele andere Programmiersprachen. C++ ist schwer, ...

    Langsam wird es mir echt zu blöd. Wenn du ein riesen-Framework hast, dann kannst du dir die Sprache nicht aussuchen. Dann musst du, wenn du irgendwas kleines für dieses Framework ändern willst, sinnvollerweise die Sprache beibehalten. Klar, wenn du dir dann aussuchen kannst, wie du weiterarbeitest, wirst du (in meinem Bereich) sicher Python wählen. Und das wird natürlich auch gemacht. Nur geht das eben nicht immer oder wäre manchmal mit unverhältnismäßig viel Aufwand verbunden. Außerdem ist "C++ ist schwer und es gibt andere Sprachen" nun in meinen Augen überhaupt kein Argument, C++ nicht zu verbessern und Fehlerquellen zu reduzieren.



  • @Bashar

    Mir geht es hier aber nicht um den Fall, in dem da tatsächlich ein Bug drin ist, sondern um die sehr viel häufigeren Fälle, in denen es keinen Unterschied macht, die man alle anpassen müsste.

    Entweder du drehst die Warnung für diese Projekte ab. Dann ist sie weg und nichts warnt dich mehr vor Fehlern. Oder du lässt sie aufgedreht und ignorierst sei einfach. Dann ist sie genau so für die Katz. Schlimmer noch: es sind dann alle Warnings für die Katz. Weil dann bald das Build-Log immer voll mit hunderten/tausenden Warnings ist und keiner mehr merkt wenn neue dazukommen.
    Oder du unterdrückst die Warning lokal. Dann kannst du den Code auch gleich anpassen.

    Klar, ich weiss dass dein Argument das Argument ist es so zu lassen wie es ist (=kein Fehler). Aber gut ist das trotzdem nicht. Es ist nur vermutlich das kleinere Übel.

    Und deswegen, weil das alles doof ist wie es ist, wurde es vermutlich bei den neu dazugekommenen aggregate initializern anders gemacht. So wie es immer hätte sein sollen.



  • @wob sagte in Ist C++ noch zu retten?:

    @Bashar sagte in Ist C++ noch zu retten?:

    Auch ein Nicht-Problem. Was wollen die alle mit C++? Es gibt soviele andere Programmiersprachen. C++ ist schwer, ...

    Langsam wird es mir echt zu blöd.

    OK. 👋

    @hustbaer sagte in Ist C++ noch zu retten?:

    @Bashar

    Mir geht es hier aber nicht um den Fall, in dem da tatsächlich ein Bug drin ist, sondern um die sehr viel häufigeren Fälle, in denen es keinen Unterschied macht, die man alle anpassen müsste.

    Entweder du drehst die Warnung für diese Projekte ab. Dann ist sie weg und nichts warnt dich mehr vor Fehlern. Oder [...]

    Irgendeinen Tod muss man sterben. Mit Warnungen ist jedenfalls leichter umzugehen als mit Fehlern.

    Klar, ich weiss dass dein Argument das Argument ist es so zu lassen wie es ist (=kein Fehler). Aber gut ist das trotzdem nicht. Es ist nur vermutlich das kleinere Übel.

    Zustimmung.

    Ich hab hier das Gefühl, mir wird unterstellt, das so gut und richtig zu finden, wie es ist. Im Gegenteil. Aber C++ ist so wie es ist, und das hat Gründe, die größtenteils nicht einfach daran liegen, dass noch niemandem aufgefallen ist, dass dieses und jenes doof ist und eigentlich auch anders sein könnte. Ich habe versucht zu mutmaßen, was diese Gründe sein könnten, mehr nicht. Vielleicht sind es ja wirklich andere, und man wird automatisch spätestens betriebsblind, wenn anfängt ein eigenes Proposal zu schreiben. Keine Ahnung.



  • @titan99_ sagte in Ist C++ noch zu retten?:

    Dann mach doch sowas:

        #include <type_traits>
        if(std::is_same<MyClass0, MyClass1>::value)
        {
            // Do something
        }
    

    Das funktioniert nicht mit Polymorphie. Wenn man typeids nutzen muss, dann spielt das Thema Polymorphie immer eine Rolle. D.h. Templates mit ihren statischen Typen sind dann mit solchen Trivialansätzen keine alternative Lösungsmöglichkeit.

    Zudem habe ich es so in Erinnerung, dass es normalerweise schlechtem Programmierstil entspricht, typeid/RTTI zu gebrauchen und es normalerweise eine einfachere Lösung gibt und es d. h. nur im Ausnahmefall zur Anwendung kommen sollte.

    RTTI nutzt man in der Regel indirekt über virtuelle member functions. RTTI wird nur bei einigen embedded Lösungen abgestellt, weil man Angst hat, dass da zu Problemen führt. typeids selbst sollte man wann immer möglich nicht nutzen. Nur bei so Themen wie Double- bzw. Mutipledispatch kann es sinnvoll sein das zu nutze. Aber auch da gibt es Alternativen. Siehe hierzu „Modern C++ Design, von Adrescu“.



  • @Bashar sagte in Ist C++ noch zu retten?:

    Aha. Und dort ist das ein Plädoyer "dafür die Reihenfolge gar nicht vorzuschreiben"?

    Ich habe nur meine Quelle genannt.

    Du brauchst nicht zu antworten. Mich nervt diese "Diskussion".

    Mich nerven massenweise unwichtige Warnungen des Compilers, wenn darunter die wichtigen Dinge im Rauschen verschwinden.



  • @john-0 sagte in Ist C++ noch zu retten?:

    Mich nerven massenweise unwichtige Warnungen des Compilers, wenn darunter die wichtigen Dinge im Rauschen verschwinden.

    Das muss ich auch immer feststellen. Ich kann mit meinen Beispielen beliebig fortfahren: Aufruf einer virtuellen Methode im Destruktor. --> Zufällig entdeckt als ich im Code eines erfahrenen Kollegen die unwichtigen Warnings entfernt habe.



  • @Steffo sagte in Ist C++ noch zu retten?:

    @john-0 sagte in Ist C++ noch zu retten?:

    Mich nerven massenweise unwichtige Warnungen des Compilers, wenn darunter die wichtigen Dinge im Rauschen verschwinden.

    Das muss ich auch immer feststellen. Ich kann mit meinen Beispielen beliebig fortfahren: Aufruf einer virtuellen Methode im Destruktor. --> Zufällig entdeckt als ich im Code eines erfahrenen Kollegen die unwichtigen Warnings entfernt habe.

    Deswegen kann man sich die Warnungen auch größtenteils selbst einstellen, was ich auch jedem raten würde.

    -Weffc++ oder -pedantic

    muss man sich ja nicht unbedingt antun. Aber in -Wall und -Wextra ist z.b. nix dabei was "nervt" oder das Log vollspammt. Es sei denn man hat schlampig programmiert 😅

    Wir haben Team-Intern/Büro-Intern die mindestens notwendigen Warnungen festgeschrieben und als Vorgabe gesetzt, dass nur Warnungsfreie Projekte nach dem Buildprozess noch im Installationspaket landen. So einfach.



  • Ist das bei anderen Sprachen alles nicht prinzipiell genauso?
    Zumindest in den weit verbreiteten.
    JavaScript ist so broken, dass "opinionated design" da extrem verbreitet ist. -> "Mache XY nur auf diese Art und Weise, weil ich weiß wie es am besten ist und alle Alternativen sind schlimm". Grausam.

    Und was ihr hier so aufzählt ist noch weit entfernt von den brutal fiesesten Sachen die mir begegnet sind. Da versteh ich schon dass die Diskussion zu Warnungen driftet.



  • @5cript sagte in Ist C++ noch zu retten?:

    "Mache XY nur auf diese Art und Weise, weil ich weiß wie es am besten ist und alle Alternativen sind schlimm". Grausam.

    Willkommen in der Wirklichkeit eines Ingenieurs - in diesem Fall halt Software-Ingenieur.



  • @hustbaer sagte in Ist C++ noch zu retten?:

    Willkommen in der Wirklichkeit eines Ingenieurs - in diesem Fall halt Software-Ingenieur.

    Ich bin der Ansicht, dass man mir in C++ 10 Umsetzungen zu einem Problem zeigen kann (in Punkto Software Design) und ich könnte für wenigstens 7 davon positiv argumentieren.
    Ohne dass ich gleich dazu neigen würde zu sagen: "nur diese eine, und der rest ist müll, weil [...]".

    Wenn man sich JavaScript Frameworks ansieht dann ist das voll von "nur so und nicht anders". Jede Fullstack Lösung und dazugehörige unerlässliche Libraries hat ihre eigene aus Erfahrung entsprungene Philosophie, die einen in eine Projekt und Softwarestruktur zwingt.

    Der Gedanke "ich weiß was gut für dich ist" stößt mir sehr auf.

    EDIT: Wichtig! Ich erkenne aber an, dass für manche libraries oft eine Abweichung vom dargelegten Workflow bedeutet dass man sich sehr viel Ärger einhandelt und was falsch macht. Das ist was ich meine wenn ich sage "JavaScript ist so broken, dass einem struktur aufgezwungen wird".



  • @5cript
    Was ich meinte ist: frag mal einen Maschinenbau-Studenten der bei einer Hausübung wo er ein Getriebe entwerfen sollte einen eigenen, neuen Entwurf abgegeben hat was sein Professor dazu gesagt hat.

    Als Ingeneur ist es deine Aufgabe bestimmte Dinge zu entwerfen die unter allen möglichen Bedingungen gut funktionieren sollen. Es ist quasi unmöglich bei einem neuen Entwurf alles zu bedenken. Was passiert wenn im Getriebe Zahnrad X bricht? Explodiert es mit schlimmen Folgen oder hört es einfach auf zu funktionieren? Was passiert wenn das Getriebeöl zu lange nicht gewechselt wird? Was passiert überhaupt wenn das Getriebe einfach nur "normal" betrieben wird? Welche Teile nutzen sich ab und wie stark und was hat das für Folgen? Wie kommt das Getriebe mit den stärkeren Vibrationen klar wenn das ZMS verschleisst und nicht mehr gut dämpfen kann?

    Bei bekannten, bewährten Designs sind diese Dinge eben bekannt, und man weiss dass sie in der Praxis gut funktionieren. Und das trotz dem man nichtmal alle möglichen Probleme kennt die andere Designs haben könnten.

    Und in der Software-Entwicklung ist es ähnlich. Daher gibt es auch diverse Muster die allgemein empfohlen werden.

    Jede Fullstack Lösung und dazugehörige unerlässliche Libraries hat ihre eigene aus Erfahrung entsprungene Philosophie, die einen in eine Projekt und Softwarestruktur zwingt.

    Wenn dich das Framework in eine Struktur zwingt, dann ist das ja keine Meinungssache mehr. Du hast dann ein Werkzeug das du auf Art X gut verwenden kannst, und alle anderen Arten funktionieren einfach nicht gut. Wenn du es dann trotzdem anders machst...

    Ich erkenne aber an, dass für manche libraries oft eine Abweichung vom dargelegten Workflow bedeutet dass man sich sehr viel Ärger einhandelt und was falsch macht. Das ist was ich meine wenn ich sage "JavaScript ist so broken, dass einem struktur aufgezwungen wird".

    Ich würde sagen das ist eine Eigenschaft von allen "Frameworks". Ja, es gibt Libraries mit denen man bestimmte Dinge gut machen kann, die einem kaum ein bestimmtes Design/eine bestimmte Struktur aufzwingen. Diese sind aber meistens spezialisiert und decken nur einen kleinen Teil davon ab was du in einer Anwendung brauchst. Wenn du dann mehrere dieser Libraries zusammenknotest und eine Anwendung damit baust bastelst du dir quasi dein eigenes Framework. Dieses hat dann auch eine Struktur, und wer auch immer die Anwendung weiter betreut sollte sich besser daran halten, denn sonst wird er genau so Probleme bekommen. Nachteile dieser Variante sind allerdings dass es meist deutlich mehr Arbeit ist, und dass keiner weiss wie sich das Design in Zukunft bewähren wird.

    Und wenn du dir grössere C++ Frameworks ansiehst, diese haben genau das selbe "Problem", also dass sie dich in bestimmte Strukturen zwingen. Nur mal als Beispiele MFC, Qt. Oder WPF für C#. Bzw. sogar Libraries wie Boost.Asio oder libuv zwingen dir bestimmte Strukturen auf - obwohl sie ja "nur" IO Libraries sind (OK, ist gelogen, sie sind eben ein wenig mehr als das). Ich glaube die empfundene Freiheit von C++ kommt eher daher, dass man in C++ seltener solche Frameworks verwendet.



  • @It0101 sagte in Ist C++ noch zu retten?:

    Ich finde es etwas übertrieben, eine ganze Sprache zu verteufeln, weil ein Feature etwas kurios ist.
    C++ kann viele Dinge, aber wie das ebenso mit mächtigen Werkzeugen ist, gibt es auch ein paar Fallen.

    @Steffo +1 🙂

    Ich bin ja auch "zwangsweise" C++ Fan. Bzw. es ist wohl mittlerweile eher eine Hassliebe nach rund 20 Jahren. Aber man sollte sich schon eingestehen, dass C++ an wirklich vielen Stellen Broken-By-Design ist. Leider werden diese Macken, dann von einer religösen C++-Gemeinde verneint und geleugnet. Schlimmer noch als wie zuweilen bei den Applejüngern. Keine Wunder, dass es dann nicht vorrangeht mit C++. Jetzt kommen dieses Jahr endlich Modules und ich bin mir sicher sie haben es voll verka... Eine Schande das nach all den Jahrzehnten diese vielen Probleme nicht angegangen oder wenn nur völlig vermurkst umgesetzt wurden. Das Beispiel von Steffo ist eines. Es gibt aber noch viele weitere. Ich wüschte mir ja ein C# so hardware nah wie C++ und plattformübergreifend/offen verfügbar. Microsoft hat hier was die Sprache anbelangt und das sage ich obwohl ich seit Jahren keines deren Produkte mehr verwende bzw. verwenden wöllte exzellente Arbeit gemacht. Dann könnte C++ sterben.



  • @Enumerator
    Volle Zustimmung.
    Nachdem Hejlsbergs Jünger jetzt auch die C-Zeiger verstanden haben und sie mittels Span<T> ab 7.0 in C# supporten - so schlecht können C Zeiger ja also nicht sein - und plötzlich laufen dann diverse C# Libs von ganz allein deutlich schneller (nur weil sie intern auf Span umgestellt wurden).
    Das ist natürlich ggü. den laienhaften Versuchen, C++ die Zeiger schmackhaft zu machen, ein ganzheitlicher Ansatz.



  • @Wutz sagte in Ist C++ noch zu retten?:

    @Enumerator
    Volle Zustimmung.
    Nachdem Hejlsbergs Jünger jetzt auch die C-Zeiger verstanden haben und sie mittels Span<T> ab 7.0 in C# supporten - so schlecht können C Zeiger ja also nicht sein - und plötzlich laufen dann diverse C# Libs von ganz allein deutlich schneller (nur weil sie intern auf Span umgestellt wurden).
    Das ist natürlich ggü. den laienhaften Versuchen, C++ die Zeiger schmackhaft zu machen, ein ganzheitlicher Ansatz.

    Niemand sagt dass C-Zeiger ( oder rohe Zeiger im Allgemeinen ) zwangsläufig schlecht sind. Ihre Verwendung ist halt unter Umständen fehleranfälliger. Daher hat man ja auch keine rohen Zeiger eingeführt sondern mit Span<T> eine Hülle drum gebaut. Wie heißt das nochmal in C++? Ach ja: Smart-Pointer.

    Warum ist das eine jetzt megageil und das andere Teufelzeug?



  • @It0101
    Weil die Stroustrup Jünger auch nach 30 Jahren immer noch neue "unentbehrliche" "Features" für C++ finden und sie unter dem Deckmantel als "Standard" hochvolatil der Allgemeinheit oktroyieren;
    jede Veröffentlichung eines solches "Standards" ist nur das Eingeständnis der eigenen Unfähigkeit, eine neue praxisrobuste Sprache zu kreieren.
    Wann wurden denn deine Smartpointer "erfunden"? Genau - viele Jahre nach Verabschiedung des 1. Standards - d.h. und noch viel mehr Jahre nach der ahnungslosen Stroustrup-Stümperei im stillen Kämmerlein;

    Wenn man keine Ahnung hat, Klappe halten und Finger weg.



  • @Wutz sagte in Ist C++ noch zu retten?:

    @It0101
    Weil die Stroustrup Jünger auch nach 30 Jahren immer noch neue "unentbehrliche" "Features" für C++ finden und sie unter dem Deckmantel als "Standard" hochvolatil der Allgemeinheit oktroyieren;

    Das mag vielleicht draussen auf der Straße funktioneren, hier im Forum befinden sich jedoch eher Leute, die viel Übung darin haben, die Semantik hinter Sprachkonstrukten zu ergründen.

    Die werden wohl recht schnell merken, dass dein Beitrag ausschliesslich Behauptugen und exakt 0 Argumente beinhaltet - nichtmal Pseudoargumente. Das ist sogar für einen Trollbeitrag ziemlich schwach.


Anmelden zum Antworten