aufteilung eines programmes in exe und dlls



  • hallo leute

    damit ich exception und die STL ueber dll-grenzen verwenden kann muss ja der selbe compiler und die selben einstellungen verwendet werden.
    jetzt kommt ja von VC2017 alle paar wochen ein neues update raus. muss ich dann bei einem update alle dlls auch wieder neu kompilieren wenn ich noch an dem programm arbeite? ich weiß ja nicht was da so alles geaendert worden ist. vorallem wenn die software mal fertig ist und ich nach ein paar monaten ein update fuer eine der dlls nachreichen will, muss ich dann alles neu kompilieren und bei den kunden installieren?
    bisher hab ich immer COM oder reine C interfaces verwendet. STL container und exceptions waeren aber schon eine feine sache und wuerden mir das leben erleichtern.
    oder gibt es vielleicht zu dem thema ein gutes buch oder dokument was jemand empfehlen kann?

    Meep Meep



  • IMO einzig richtige Lösung: Über DLL Grenzen hinweg nur ein stabiles ABI wie reines C, COM oder WinRT verwenden...

    Wenn es sich bei diesen DLLs um Module handelt die fixer Bestandteil der Kernanwendung sind, solltest du dir die Frage stellen, wieso die jeweiligen Dinge unbedingt in einer DLL sein müssen und ob eine normale LIB es nicht auch tun würde...



  • nein, die sind kein fixer bestandteil der kernanwendung.



  • hat eine LIB nicht die selben einschraenkungen wie eine DLL ?



  • Meep Meep schrieb:

    hat eine LIB nicht die selben einschraenkungen wie eine DLL ?

    Eine lib wird direkt in deine .exe gelinked. Das setzt natürlich voraus dass die lib mit dem exakt selben Compiler und den exakt selben Flags kompiliert wurde wie der Rest der exe. Für die dll gilt – wenn du C++ im Interface haben willst – aber uneingeschränkt das selbe. Wenn du also nicht aus irgendeinem Grund wirklich eine dll brauchst (z.B. weil du das Module dynamisch laden/entladen oder separat servicen können musst oder sowas), dann macht die lib mehr Sinn weil Whole Program Optimization und so...



  • Wir aktualisieren den Compiler auf der Buildfarm halt nicht so oft. So in etwa ein mal pro Jahr kommt ein größeres Release raus, und so lang läuft da eine Compilerversion drauf (wenn sich nicht was gravierendes ändert). Beim nächsten Release schauen wir dann mal, dass wir den Compiler aktualisieren, damit man dann auch die allerneuesten C++ Features nutzen kann.
    Aber halt nicht die ganze Zeit mittendrin. Ein Compilerwechsel ist durchaus nicht unproblematisch, zumindest mit irgendwelchen 3rdparty Libs usw. gibts immer Probleme und da muss man Zeit investieren, also so ohne ist es bei uns sowieso nicht.



  • hat eine LIB nicht die selben einschraenkungen wie eine DLL ?

    beim linker werden die "Symbole" beim linkvorgang direkt verknüpft, quasi gleich verdrahtet.
    Bei der Dll werden die Exportierten Funktionen und Paramter zur laufzeit verknüpft.

    Der praktische unterschied ist meist, das linkerSymbole viel mehr Informationen übertragen als die Einträge in der Import-Tabelle.
    ALso setzt du nen wichtiges flag anders, heissen die Symbole anderes, werden nicht verlinkt -> linkererror.

    Bei ner dll geht das vielleicht durch. Und dann zur runtime, bevorzugt beim kunden, tolles verhalten, exceptions, etc.

    Bei ABI definierten (C) Interfaces ist das dann aber egal, weils da keine Unterschiede geben darf, da ist genau festgelegt, was wo steht wie aufgelöst wird. wer stack aufräumt ... bzw kann man das direkt beeinflussen (Padding z.b.).
    diese ABI kennt dann aber keine C++ Elemente, wie exceptions, templates, klassen ...

    In der Praxis kann man aber nicht alles in C Interfaces giessen, und ne C++ ABI läßt leider auf sich warten.

    deswegen gibts faulte kompromisse .... z.b. kannst du technisch alles in dlls packen wenn du garantieren kannst, das exe und dll IMMER mit gleichen Einstellungen compiliert wird. Kann man oft halt nicht.

    Dlls machen wirklich technich Sinn, wenn:
    - wirklich dynamisch geladen wird (also wirklich nur bei bedarf, also mit loadlibrary und co)
    - wenn man Compiler einstellungen entkoppeln will (Einstellungen von 3d party libs/treiber vorgeschrieben kriegt, die man in der App nicht haben will)
    - oder wenn die Dll wirklich eine seperat gewartete Komponente ist (fokus liegt auf Wiederverwendbarkeit/Stabilität)

    Bei allen anderen Fällen bringen Dlls eher technisch mehr Probleme als Vorteile.
    Auf der Anderen Seite wird bei ner Dll Schnittstelle durch die technsichen Anforderungen und das expliziete Exportieren oft auch das Schnittstellendesign sauberer und durchdachter, was ne positive Auswirkung auf die Architektur hat (Komponentendesign)

    Ciao ...


Log in to reply