CODEWITHSUNDEEP
c++windowsvisual-c++dll
naiveCoder
naiveCoder

Reputation: 1007

exe and dll sharing the same static libraries

i have my solution for my application set up the following way - ( i am using Visual Studio and this is a VC++ project )

App Library dependency diagram

NOTE: Blue projects are compiled as static libraries.

as you can see, the exe and dll shares some of the static libraries ( core.lib and utils.lib ) and exe in-turn uses the DLL ( through "load time dynamic linking" using import library).

my question is is it a correct dependency-setup to have ? the problem i see is, when this app is up and running, there will be some duplicate code in the process address space right ? meaning, all the functions that are there in Core.lib and Utils.lib will appear twice right ? cos, the Exe and DLL will have this code separately compiled into them.

if yes, one way of dealing with the above issue is to move the code exclusive to dll or keep in exe and share it (b/w exe and dll) through import/export. but i have many class objects in core and utils and i dont like the idea of exporting/importing these class objects ( by appending __declspec(dllimport/dllexport)) in the header files and besides i might end up adding this to lot of dependent class objects

this is my understanding and i might be wrong. please suggest corrections and what is the usual approach followed to deal with such problems ?

Regards,

Upvotes: 11

Views: 3670

Answers (4)

Dennis Ward
Dennis Ward

Reputation: 757

I've run into this problem also, and had a Manager class that was a supposed to be a singleton which contained a map of handles to objects, through a static instance variable (which contained the std::map<handle,object>).

I had placed this in a static library, and found that my singleton was duplicated in each DLL or EXE that linked to it, rendering my singleton useless (wasn't a singleton at all, but one instance per DLL/EXE that linked to my library), causing object lookups by handle to fail because there were multiple instances/maps.

To resolve this, I placed my "manager" class in a DLL to avoid any duplication.

Upvotes: 2

milevyo
milevyo

Reputation: 2184

my suggestion is: just keep codding the way it is, until a problem rises or an extremely need for the change appears.

Upvotes: -1

stefan
stefan

Reputation: 3759

if you go DLL you must go DLL all the way, all dependencies down to the c-runtime. code duplication (memory footprint) is not the worst problem. remember, memory allocated by the app cannot be freed by a dll and vice versa, unless both use the very same runtime (dll).

Upvotes: 2

dhanushka
dhanushka

Reputation: 10682

Yes, the Core and Utils code will be duplicated. Instead of building them as static libs you can build them as dlls and use anywhere.

Upvotes: 2

Related Questions