C++11, C++14, C++17 - Modernes C++ bei euch schon angekommen?

Bei C++ tut sich ja einiges. Es gibt immer mehr neue Neuerungen.

Nutzt ihr sie aber auch? Ist modernes C++ bei euch schon in der Praxis angekommen oder hält euch die Gewohnheit oder bestehende Projekt Konventionen immer noch fern davon?

Und ist es wirklich sinvoll C++ mit immer mehr Features zu versorgen ohne dass die Altlasten nicht entfernt werden?
Wird es so in Zukunft nicht noch länger dauern bis jemand sämtliche Sprachkonzepte und Code Varianten kennt?

Es wird immer Leute geben die den neuen Konventionen nicht folgen und alten Syntax mit neuem vermischen.
Man kann also schlecht sagen dass man sich nur noch auf modernes C++ konzentrieren möchte.
Geht nur so lange bis man auf Code stößt wo jemand immer noch "altes" C++ einsetzt oder mit modernem vermischt.

Was spricht dagegen zukünftige Compiler Versionen nur noch modernes C++ übersetzen zu lassen?
So das in neuen Projekten irgendwann wirklich nur noch moderne Konzepte genutzt werden.
Wer nicht möchte oder nicht kann kann ja immer noch ältere Compiler einsetzen.

Irgendwann und irgendwie muss man sich von Altlasten eines Standards befreien können.

5cript

Überall C++14. Auf Arbeit, github und daheim.
(Bzw C++11, wenn ich mit dem C++ Builder auf der Arbeit arbeite, aber der ist ja auch Krebserregend).

Ich werde C++17 vermutlich erst nächstes Jahr anfangen zu benutzen.

Btw: Was denn für Altlasten zb?
Ich finde das neues relaaatiiv gut aufbaut auf altem C++. Wir wollen schließlich nicht ein Python Split Desaster.

EDIT: C++11 ist absolutes minimum. Ich weigere mich C++98 zu schreiben, das kann ich vermutlich sogar gar nicht mehr. Und ist auch gar nicht nötig.
Der einzige Bereich wo ich nicht weiß wie es aussieht sind C++ compiler für Mikroprozessoren.

Artchi

C++11 usw. ist in meinen Augen viel Syntaktik Sugar. Nichts was man machen muss oder einen wirklich hilft Probleme zu lösen, die man vorher nicht lösen konnte. Ganz wenige neue Sprachfeatures sind für mich sehr interessant, wie die for-each-Schleife und auto.

Ansonsten programmiere ich weiter wie zu C++98-Zeiten.

Viel wichtiger ist für mich der Ausbau der C++-Standard-Bibliothek! Und dafür nutze ich C++11/14 tatsächlich sehr gerne.

Hugo012 schrieb:

Und ist es wirklich sinvoll C++ mit immer mehr Features zu versorgen ohne dass die Altlasten nicht entfernt werden?

ja, denn die weitgehende Rückwärts-Kompatibilität ist eines besonders wichtigen Features von C++ im Sinne der Investitionssicherung. Vor ein paar Monaten habe ich mit einem aktuellen Compiler 16 Jahre alten Code kompiliert und das ging völlig problemlos.

Hugo012 schrieb:

Was spricht dagegen zukünftige Compiler Versionen nur noch modernes C++ übersetzen zu lassen?

es spricht dagegen, dass du in Ermangelung eines einheitlichen Formats für C++ Objectfiles wahrscheinlich auch die Libraries, sofern sie kein extern "C" Interface haben, mit dem "nur noch modernes C++"-Compiler bauen mußt, mit dem du deinen Anwendercode baust. Was wiederum bedeutet, dass alle Libraries, von denen dein code abhängt, "nur noch modernes C++" sein dürfen. Da du aber auf den Code-Style von Third-Party Libraries eventuell gar keinen Einfluss hast, hast du dann schnell ein Problem.

Hugo012 schrieb:

Irgendwann und irgendwie muss man sich von Altlasten eines Standards befreien können.

Dumm, wenn man dann Code hat, der irgendwann mal -zigtausend Mannstunden gekostet hat und jetzt nicht mehr kompiliert ohne ihn an tausend Stellen zu ändern.

zufallswert schrieb:

Was wiederum bedeutet, dass alle Libraries, von denen dein code abhängt, "nur noch modernes C++" sein dürfen.

Einschränkung: Das bezieht sich natürlich auf diejenigen Libraries ohne extern "C"-Interface, wie im Satz vorher.

audacia

Alles Neue ist C++14 und wird C++17, sobald VC++ mit auto -Templateargumenten klarkommt. (Die meisten noch ausstehenden C++17-Features wie fold expressions und pack expansion in using declaration vereinfachen nur den backstage-Code in meinen Bibliotheken, aber nicht den Anwendercode.)

Es mag schon sein, daß man als Anwender ganz gut mit C++98 plus auto und range-based for loop auskommt. Aber man sollte bedenken, wie die Bibliotheken aussähen (bzw. aussahen) ohne variadic templates, static_assert() , type traits, initializer lists, Lambda-Funktionen oder constexpr , und wie viel Kontakt man also unvermeidlich mit C++1x-Features hat, ohne sie explizit zu gebrauchen.

Artchi

Die Bibliotheken mögen gerne die neuen komplexen Sprachfeatures nutzen. Und ich als Benutzer profitiere davon. Aber nicht jeder ist Bibliotheks-Entwickler. Ich will mich damit auch gar nicht auseinander setzen, ich will meine Anwendungen fertig bekommen. Und dann ist mir der Coolness-Faktor egal.

Die Anwendung muss fehlerfrei und schnell laufen. Und ich muss es schnell fertig bekommen.

Dafür reicht mir hauptsächlich das C++98 plus die neue Standard-Lib.

Ich würde es deshalb eher begrüssen, wenn endlich die Header-Dateien verschwinden würden, damit man nicht andauernd die DRY-Regel bricht und sich auf die eigentliche Problemlösung konzentrieren kann.
Das würde C++ endlich in das aktuelle Jahrtausend katapultieren.

Artchi schrieb:

Ich würde es deshalb eher begrüssen, wenn endlich die Header-Dateien verschwinden würden, damit man nicht andauernd die DRY-Regel bricht und sich auf die eigentliche Problemlösung konzentrieren kann.

wozu soll das gut sein, dass die Header-Dateien verschwinden?

Der Compiler muss beim Aufruf von externen Funktionen deren Signatur kennen, sonst kann er keine Typprüfung durchführen und keinen Typsicheren Code für den Aufruf der externen Funktion produzieren.

Wie soll das ohne ein Header-File mit den entsprechenden Prototypen gehen, wenn die externe Library nicht open-Source ist (im Fall open Source wäre es immerhin möglich, dass der Compiler den Quellcode der Library durchgeht und sich die Prototypen selber herstellt)?

Du wirst die header files alleine aus backwards-compability gruenden nicht weg bekommen...

zufallswert schrieb:

(Artchi schreibt, warum er Headerdateien loswerden will)

wozu soll das gut sein, dass die Header-Dateien verschwinden?

zufallswert schrieb:

Der Compiler muss beim Aufruf von externen Funktionen deren Signatur kennen, sonst kann er keine Typprüfung durchführen und keinen Typsicheren Code für den Aufruf der externen Funktion produzieren.

Wie soll das ohne ein Header-File mit den entsprechenden Prototypen gehen

Vielleicht hast du das nicht mitbekommen, aber dieses Problem ist in praktisch jeder seit den 70ern entwickelten Sprache ohne Headerdateien gelöst worden. Spezifisch für C++ gibt es das "Modules-TS", das es vielleicht nach C++20 schafft.

dieses "Problem", wie du es nennst, ist kein Problem, sondern eine Lösung

audacia|off schrieb:

zufallswert schrieb:

wozu soll das gut sein, dass die Header-Dateien verschwinden?

Vielleicht hast du das nicht mitbekommen, aber dieses Problem ist in praktisch jeder seit den 70ern entwickelten Sprache ohne Headerdateien gelöst

von den "praktisch jede"-Sprachen "seit den 70ern", die du hier wohl meinen könntest, hört man aber relativ wenig, verglichen mit C.

Ein Indiz dafür, dass Header-Files und Funktions-Prototypen doch keine so dumme Idee sind?

Artchi

zufallswert schrieb:

von den "praktisch jede"-Sprachen "seit den 70ern", die du hier wohl meinen könntest, hört man aber relativ wenig, verglichen mit C.

Klar, diese Sprachen sind total Praxisfern und unbekannt:

D
Rust
Go
Eiffel
OCaml
C#
Java

Irgendwie ist nur C und C++ noch mit Header-Files unterwegs. Der Rest der Programmierwelt schafft es komischerweise ohne auszukommen. Nur C und C++ haben die Lösung, die anderen haben nur Probleme.

hustbaer

Artchi schrieb:

Klar, diese Sprachen sind total Praxisfern und unbekannt:

D
Rust
Go
Eiffel
OCaml
C#
Java

Naja von den ersten 5 auf der Liste hört man wirklich vergleichweise wenig. Was ja die Behauptung war, nicht dass die alle total praxisfern und unbekannt wäre.

hustbaer

zufallswert schrieb:

Ein Indiz dafür, dass Header-Files und Funktions-Prototypen doch keine so dumme Idee sind?

Nein. Ein Indiz dafür dass C und C++ insgesamt immer noch so relevant sind dass man sie immer noch verwendet, trotz dem sie diverse Schwächen haben. Wie z.B. die Sache mit den Header-Files.

Artchi

Schon alleine die Include-Guards sind einfach nur lästig.

Ich kann absolut nichts gutes an den Headern finden.

Naja von den ersten 5 auf der Liste hört man wirklich vergleichweise wenig. Was ja die Behauptung war, nicht dass die alle total praxisfern und unbekannt wäre.

Das ist ja nun wirklich kein Argument, ob etwas technisch umsetzbar ist? Denn es wurde ja angezweifelt, das es technisch sinnvoll ist. dann mögen zwar die Beweise nicht so verbreitet sein, aber sie belegen die technische Machbarkeit.

hustbaer

@Artchi
Er. Klar ist es technisch (recht einfach) machbar, bei Sprachen die kein Legacy-Gedöns mitzuschleppen haben.

Für C++ ist es auch machbar, nur halt nicht so einfach wie wenn man von der grünen grünen Wiese wegstartet. Und daher noch nicht fertig. Kommt aber.

Egal.
Dass Headers nicht so toll sind, darüber sind wir uns ja einig

Artchi

Ach ja, Swift von Apple habe ich natürlich vergessen. Das wird doch sicherlich unter OSX und iOS bei neuen Projekten vermehrt eingesetzt?

Swift wollte ich mir auch noch mal anschauen...

hustbaer schrieb:

zufallswert schrieb:

Ein Indiz dafür, dass Header-Files und Funktions-Prototypen doch keine so dumme Idee sind?

Nein. Ein Indiz dafür dass C und C++ insgesamt immer noch so relevant sind dass man sie immer noch verwendet, trotz dem sie diverse Schwächen haben. Wie z.B. die Sache mit den Header-Files.

Doch! Funktionsprototypen und Header-Files sind eine im Grunde genial einfache, flexible und zweckmäßige Lösung für das Problem der Typprüfung zur Compile-Zeit bei Aufrufen externer Funktionen. Hätte gar nicht gedacht, dass es über diesen Punkt so viel zu diskutieren gibt.

Wen es stört - schreibt doch ein Tool, das die Prototypen aus den Implementationsdateien automatisch extrahiert. Mich stört das ctrl-c ctrl-v zum Kopieren der Signatur ins Header-File nicht.

Artchi

Copy & Paste Das ist das erste was ich unseren Fachinformatik-Azubis austreibe! Copy & Paste machen wirklich nur Anfänger gerne ohne sich zu schämen.

Und wenn du mal eine Signatur änderst? Dann musst du wieder an einer anderen Stelle anfassen, was du kopiert hast. Also wie man das ohne rot zu werden propagieren kann, ist mir unverständlich.

DON'T REPEAT YOURSELF! würde ich dir raten, als großen Banner in dein Büro zu hängen.