Forwärtsdeklaration: Wo macht das Sinn?



  • Hey, das ergibt absolut Sinn, was du da sagst, Mechanics! 🙂

    L. G.,
    IBV


  • Mod

    Stellt sich natürlich die Frage, wieso das Framework keine Header mit Forwarddeklarationen zur Verfügung stellt, wenn Vorwärtsdeklarationen praktisch tatsächlich so einen großen Einfluss auf den Compiliervorgang haben.



  • camper schrieb:

    Stellt sich natürlich die Frage, wieso das Framework keine Header mit Forwarddeklarationen zur Verfügung stellt, wenn Vorwärtsdeklarationen praktisch tatsächlich so einen großen Einfluss auf den Compiliervorgang haben.

    Na weil #include eine Datei von der Festplatte lesen muss, was langsam ist!!!11



  • camper schrieb:

    Stellt sich natürlich die Frage, wieso das Framework keine Header mit Forwarddeklarationen zur Verfügung stellt, wenn Vorwärtsdeklarationen praktisch tatsächlich so einen großen Einfluss auf den Compiliervorgang haben.

    Woher soll das Framework wissen, welche Vorwärtsdeklaration du brauchst? Soll es einfach alles vorwärtsdeklarieren, was es zu vorwärtsdeklarieren gibt?



  • rootofallevil schrieb:

    Na weil #include eine Datei von der Festplatte lesen muss, was langsam ist!!!11

    Jupp, historisches Ansinnen das.
    Inzwischen gibt es genug RAM. Schon überhaupt nicht mehr davon zu reden, an langsamen SSDs zu hängen. Außerdem werden Headers viel seltener geändert als Implementierungsdateien; bei großen Projekten tut man der Compilezeiten wegen gleich weniger Code in Header schreiben. Man muss sich da nicht viel quälen.



  • IBV schrieb:

    Woher soll das Framework wissen, welche Vorwärtsdeklaration du brauchst? Soll es einfach alles vorwärtsdeklarieren, was es zu vorwärtsdeklarieren gibt?

    Genau. Siehe z.B. <iosfwd>.



  • IBV schrieb:

    Woher soll das Framework wissen, welche Vorwärtsdeklaration du brauchst? Soll es einfach alles vorwärtsdeklarieren, was es zu vorwärtsdeklarieren gibt?

    Klar. Oder wenigstens sehr viel und alle "schweren" Headers. Auf jeden Fall wäre dort der viel Effekt größer, als wenn man es bloß als Benutzer macht (aber "größer" impliziert nicht "groß").

    Nicht zu vergessen Pimpl, das reduziert Header-Abhängigkeiten auch, läßt sich so gestalten, daß es im Release-Build aus ist, oder man läßt es an und macht so die Binärschnittstelle viel beständiger.



  • In grossen Projekten machen Forward Declarations schon Sinn.
    Kann die Compilezeiten schnell auf die Hälfte oder noch weniger runterbringen.
    Und wenns mit nem kompletten Rebuild mal auf ne Stunde oder gar mehrere Stunden zugeht, dann ...

    Nur dann ist's oft schon zu spät, weil es verdammt lange dauern würde überall dort wo man es ursprünglich nicht gemacht hat die Forward-Declarations nachzuziehen, bzw. die Forward Declaration Headers statt der "vollen" Headers zu inkludieren.



  • volkard schrieb:

    Andererseits, so ein i7… Was soll der Geiz? Hab seit laangem nicht mehr über ganz normales Sparsam-Includieren die Compilierzeit optimiert.

    Bei meinen Privatprojekten bin ich mittlerweile dazu übergegangen einfach alles in Header zu schreiben. Selbst wenn ich System-Header oder sowas brauche die ich verstecken will, baue ich das so auf, dass ich zwei separate .hpp Dateien habe und die zweite am Ende meiner main.cpp #include. Hab jetzt auch bei 30+ Dateien noch kein Großes Problem damit gehabt. Man macht so halt quasi immer nen full-rebuild, aber dafür hat man nur eine einzige Übersetzungseinheit, was dazu führt dass die ganzen Templates im Code (die nun mal in Headern stehen müssen) auch alle nur ein mal kompiliert werden. Bei 250+ Dateien wird es vmtl wieder langsamer, aber für weniger reichts und ist erstaunlich angenehm. 🤡



  • volkard schrieb:

    Andererseits, so ein i7… Was soll der Geiz? Hab seit laangem nicht mehr über ganz normales Sparsam-Includieren die Compilierzeit optimiert.

    War wohl mißverständlich. Gemeint war

    Andererseits, so ein i7… Was soll der Geiz? Hab seit laangem nicht mehr über ganz normales Sparsam-Includieren hinaus die Compilierzeit optimiert.

    Das ganz normale Sparsam-Includieren macht Wald-Und-Wiesen-Projekte schon mindestens dreimal so schnell compilierbar und senkt Einfluss und Notwendigkeit anderer Tricks. Die könnt Ihr natürlich gerne treiben, ich werfe halt mal in den Raum, daß sie vielleicht mit jedem weiteren Jahr weniger notwendig werden.



  • Aaaaaaa, OK 🙂
    Ja, war misverständlich.


Anmelden zum Antworten