PIMPL: Doppeländerung der Deklarationen umgehen?

Finnegan

hustbaer schrieb:

Was aber wirklich nervt ist eben der unglaubliche #include-creep der sich so ansammelt. Du willst eigentlich nur auf irgend eine Helper-Klasse zugreifen, und auf einmal hast du 50 Boost Headers, 10 Crypto++ Headers, noch etliche Xerces Headers und fast das ganze Windows SDK reingezogen. Die Build-Zeiten sehen dann entsprechend aus. Und Precompiled-Headers helfen da auch nur sehr bedingt.

Ich freue mich schon auf den Zeitpunkt, wenn wir über diesen altmodischen Quark nur noch lachen können und einfach schreiben:

import std.io;
   import boost.super_cool;
   import windows.cant_do_it_without_it;

... und die Datei dann genau so schnell gebaut wird wie ein "Hallo, Welt"-Programm

Finnegan (Modules-Fan, auch wenns ein bissl wie Java aussieht)

Techel

Amen.

hustbaer

Jopp. Wobei ich nicht damit rechne dass das in diesem Jahrzehnt noch kommt.

Columbo

hustbaer schrieb:

Jopp. Wobei ich nicht damit rechne dass das in diesem Jahrzehnt noch kommt.

Wie kommste darauf?

volkard

hustbaer schrieb:

Manche thirdparty Libs vertragen sich einfach nicht mit dieser oder jener anderen Header

Jo, zum Beispiel weil die thirdparty Libs alle die selbe andere thirdparty Lib benutzen aber in verschiedenen Versionen.
Da kriegste aber auch ohne Header Ärger, z.B. wenn die Oracle-CLient-Lib-DLL Funktionen von Kerberos exportiert.

hustbaer schrieb:

Was aber wirklich nervt ist eben der unglaubliche #include-creep der sich so ansammelt. Du willst eigentlich nur auf irgend eine Helper-Klasse zugreifen, und auf einmal hast du 50 Boost Headers, 10 Crypto++ Headers, noch etliche Xerces Headers und fast das ganze Windows SDK reingezogen. Die Build-Zeiten sehen dann entsprechend aus.

Kann ich nicht nachvollziehen.

hustbaer

Arcoth schrieb:

hustbaer schrieb:

Jopp. Wobei ich nicht damit rechne dass das in diesem Jahrzehnt noch kommt.

Wie kommste darauf?

Wie ich darauf komme: weil es super überhaupt gar nicht trivial ist.
Ich hab' aber nicht verfolgt für was es schon konkrete, gut ausgearbeitete Proposals gibt und für was nicht.
Ich hab nur gelesen dass es für C++17 nicht fix vorgesehen ist. Und wenn man mal annimmt dass es sich für nicht ausgeht, dann wird es mit 1x halt schon eng. Ich rechne halt kaum damit dass der Standard nach C++17 schon 18 oder 19 rauskommen wird.

Wäre aber natürlich cool wenn es sich trotzdem noch ausgeht.

hustbaer

volkard schrieb:

hustbaer schrieb:

Was aber wirklich nervt ist eben der unglaubliche #include-creep der sich so ansammelt. Du willst eigentlich nur auf irgend eine Helper-Klasse zugreifen, und auf einmal hast du 50 Boost Headers, 10 Crypto++ Headers, noch etliche Xerces Headers und fast das ganze Windows SDK reingezogen. Die Build-Zeiten sehen dann entsprechend aus.

Kann ich nicht nachvollziehen.

Is jetzt ein bisschen unspezifisch, nen?

volkard

hustbaer schrieb:

volkard schrieb:

hustbaer schrieb:

Was aber wirklich nervt ist eben der unglaubliche #include-creep der sich so ansammelt. Du willst eigentlich nur auf irgend eine Helper-Klasse zugreifen, und auf einmal hast du 50 Boost Headers, 10 Crypto++ Headers, noch etliche Xerces Headers und fast das ganze Windows SDK reingezogen. Die Build-Zeiten sehen dann entsprechend aus.

Kann ich nicht nachvollziehen.

Is jetzt ein bisschen unspezifisch, nen?

Bei mir sammelte sich noch nie #include-creep an. Habe aber Nachbarprojekte gesehen, die das Problem hatten. Ich nahm immer an, daß sie bloß sparsamer includen müßten, dann wäre das Problem weg. Und vielleicht zur Not gelegentlich einen kleinen Trick anwenden, aber sicher nicht chronisch zu pimpln.
Ich schreibe aber schon mal gerne "#ifdef WINDOWS typedef void* os::File;" oder sowas, um plattformunabhängig zu werden und zugleich die <windows.h> aus dem Header los zu sein.

Eisflamme

Gut, Tipparbeit war kein gut gewähltes Wort.

Doppelarbeit zu vermeiden und Code zu wiederholen finde ich jedoch durchaus schlecht. Und wenn ich eben von außen nach innen viel Zeug weiterreiche und das private Interface dann zu 95% eine Untermenge des öffentlichen Interfaces ist, habe ich schon den Eindruck, dass hier was schief gelaufen ist.

Ändere ich bei einer Durchreich-Methode einen Parameter, muss ich das an vier Stellen ändern. Das kann's doch nicht sein.

Lösungsvorschläge dafür wurden hier ja aber angeboten, ihr könnt also eure Side-Discussion gerne weiterführen. Für mich ist der Thread erledigt.

Shade Of Mine

Eisflamme schrieb:

Ändere ich bei einer Durchreich-Methode einen Parameter, muss ich das an vier Stellen ändern. Das kann's doch nicht sein.

Refactoring deiner IDE verwenden.

Aber wie gesagt: die Zeit die du damit verbringst sollte unglaublich klein sein. In der Zeit in der ich mich mit den Thread beschäftigt habe kann ich vermutlich schon Jahrelang solche Änderungen machen.

Klar ist es nervig, gerade wenn die IDE nicht jedes Refactoring gut genug unterstützt dass man machen will, aber ich verbringe locker die 100fache Zeit mir einen Namen einer Funktion auszudenken als durchgereichte Parameter anzupassen.

hustbaer

@volkard
Ja, stimmt schon, man kann andere Dinge tun um #include creep entgegenzuwirken.
Tut man aber wenig bis nix, dann wird es irgendwann schlimm.
Und PIMPL ist halt sehr effektiv gegen #include creep.

volkard schrieb:

aber sicher nicht chronisch zu pimpln.

Sagt ja auch keiner was von chronisch. Das nimmst bloss wieder du an. Warum darf sich jetzt jeder denken.
Dort wo es Sinn macht halt.

Eisflamme

Shade of Mine:
Entweder ich tippe extrem langsam oder denke recht schnell, vermutlich ersteres. Jedenfalls kostet es mich schon Zeit und Nerven gleich dazu. Für Visual Assist X habe ich gerade kein Geld über, und VS selbst kann das ja nicht... darum ist die händische Variante zurzeit die beste Wahl.