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



  • zufallswert schrieb:

    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.

    Entweder du trollst, oder du bist ganz schön renitent.

    Welchen Vorteil soll es denn haben, statt eines Modulsystems wie in Java oder C# diese Headerdateien zu verwenden?



  • @zufallswert
    Nehmen wir als Beispiel eine Klasse Foo die private Member mit 5 verschiedenen eigenen Typen hat. Diese 5 Typen haben sagen wir mal wieder Member mit in Summe 15 verschiedenen eigenen Typen. Und diese wiederrum brauchen sagen wir in Summe 40 verschiedene #includes, z.B. aus der STL, Boost etc. Das ist nicht wirklich unrealistisch.

    Wenn du
    #include "Foo.h"
    schreibst ziehst du damit also 21 eigene Headers + 40 fremde (Boost, STL, ...) Headers an. Wobei die fremden Headers natürlich auch wieder weitere fremde Headers anziehen. In Summe kommst du ganz schnell auf etliche hundert Headers. Mit etlichen zigtausend~hunderttausend Zeilen Code (Prototylen, Klassendefinitionen inklusive Inline implementierter Funktionen etc.).
    Dabei sind dann "ein paar" Templates. Je "moderner" desto mehr. Auch schnell mal ein paar hundert oder gar tausend in Summe. Wovon dann ein paar zig bis hundert wirklich instanziert werden.
    Bam, Oida!

    Und wenn wir davon ausgehen dass die Klasse Foo nichts inline implementiert hat, dann brauchen wir das ganze nur, damit man sizeof(Foo) ausrechnen kann und damit der Compiler "glücklich" ist (Information über Memberfunktionen sämtlicher Klassen ausser Foo würden ja z.B. gar nicht benötigt.)
    OK, eine Kleinigkeit hab' ich unterschlagen: die implizit definierten "special member functions" (copy-ctor und so).
    Aber auch da bräuchte man eigentlich nur jeweils die Info ob es sie gibt und was ihre genaue Signatur ist.

    Es müssen also zigtausend Zeilen Code geparsed werden, nur damit ein paar wenige Integers (sizeof) und Signaturen (special member functions) errechnet werden können + damit keine "language rules" verletzt werden (z.B. dass sämtliche Memberfunktionen direkt in der Klassendefinition angegeben werden müssen, auch wenn man sie in der Translation-Unit gar nicht braucht).

    Und jetzt sag mir dass das effizient ist. Ist es nicht.

    Ich hab' nicht grundsätzlich ein Problem damit dass es schöne Textfiles gibt wo man die API nachlesen kann. Aber ich hab' ein Problem damit wenn das zu unsäglich langsamen Compilevorgängen führt. 10+ Sekunden zum Parsen nur der #includes für ein einzelnes .cpp File sind echt keine Seltenheit.

    Und was mMn. auch nicht so toll ist, ist dass Code, damit er "geinlined" werden kann, im Header File stehen muss. (Klar, das muss er nicht mehr wenn man LTCG verwendet. Nur LTCG macht alles NOCH viel langsamer. Von daher...)



  • audacia schrieb:

    Welchen Vorteil soll es denn haben, statt eines Modulsystems wie in Java oder C# diese Headerdateien zu verwenden?

    Ich sehe es als Vorteil dass man, ohne irgendwelche Tools, die Headers aufmachen und sich die API angucken kann.

    Ich würde dies aber liebend gerne gegen schnellere Compilezeiten und die anderen Vorteile eintauschen 🙂

    Vorausgesetzt dass es Tools gibt, mit denen man die relevanten Informationen aus den Modules extrahieren kann. Aber da sich diese Tools automatisch einfinden werden wenn wir erstmal Modules haben, egal ob sie mit der Implementierung mitkommen oder nicht...



  • Was genau ist bei Modulen anders als bei Header Files?
    Im Prinzip sollte beides das gleiche sein.

    Bei Modulen muss ich doch auch jedes mal alle benötigten Module einbinden und dass können dann auch immer mehr und mehr werden bei großen Projekten.

    Bitte um Aufklärung. 😕



  • Und was spricht dagegen die Definition der Klassen in den Header Dateien durchzuführen statt in .h und .cpp aufzuteilen?



  • Artchi schrieb:

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

    Für Vorschläge zur Ausstattung meiner Büros bitte an meine Innenarchitektin wenden ... 😃 LOL



  • Klaus56 schrieb:

    Was genau ist bei Modulen anders als bei Header Files?
    Im Prinzip sollte beides das gleiche sein.

    Bei Modulen muss ich doch auch jedes mal alle benötigten Module einbinden und dass können dann auch immer mehr und mehr werden bei großen Projekten.

    Ich weiss nicht was für C++ Modules genau geplant ist, aber man kann da einiges schneller machen.
    Schonmal dadurch dass man in Modules keinen Source-Code abspeichern muss. Man könnte z.B. direkt Parsebäume o.ä. abspeichern.

    Man muss sich bloss mal angucken wie schnell Precompiled-Header-Files mit MSVC funktionieren. Gut, ganz so schnell wird man es vielleicht nicht hinbekommen, da MSVC Precompiled-Header-Files von etlichen Compiler-Internals abhängig sind, und man will vielleicht nicht dass ein Module bei jedem Update des Compilers inkompatibel wird und neu gebaut werden muss. Aber ein massiver Speedup sollte dennoch drinnen sein.

    Und theoretisch wäre es mMn. auch möglich Dinge bei den Modules wegzulassen die das Module nicht exportiert.

    Also für den Fall dass mein Module die Klasse Foo exportiert, welche als Member ein Bar drinnen hat was wiederrum aus einem anderen Module kommt - dann wäre es mMn. nicht unbedingt nötig dass ein Benutzer von dem Foo Module auch das Bar Module importiert, so lange er das Bar Member nicht direkt angreift. Das würde nochmal einiges einsparen.



  • Ich würde mich schon über C++11 oder sauberes C++98 freuen... (C++ Builder; Compilierung unter Clang haben wir wegen der extremen Compilierungszeiten nicht mehr aufgegriffen).


Anmelden zum Antworten