• Advertisement

Archived

This topic is now archived and is closed to further replies.

C++ static libs vs DLL's . The basics.. I thought?

This topic is 5494 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Recently brought this up at work, and with some friends, and was suprised by the number of mixed answers. Apparently everyone had partial info, and a lot of rumors, but nobody had strong convictions on the use of DLL's or static libraries. You'd think this would be a staple of C++ design, but it seems to be more a side-effect. So, to get it straight in my head, since i've got a chance to put some of this into use in a new project,I thought i'd ask a larger audience.. You! Pure C/C++ of course. 1) What (if any) do you see as the biggest benefits to dll's. and static libraries. 2) Would you recomend against deriving classes across library boundaries? (base class in another library) Would DLL or Static link make a difference? 2b) Would it make sense to put major component abstracts in a separate library from their implementations? Could this allow implementations to be patched / changed easier perhaps? Thanks for any thoughts. Eazz [edited to remove ambiguity from question 2] [edited by - Eazz on February 6, 2003 7:04:53 PM]

Share this post


Link to post
Share on other sites
Advertisement
dlls provide for:
- more efficient code sharing, especially if many applications use certain code (windows dlls, c runtime)
- easier patching if you have a bug in the dll - all apps using the dll are automatically patched
- possible installation conflicts when installers overwrite newer dlls with older ones, or replace one language dll with another

libs provide for:
- better isolation of your application. installing a new version of dll that breaks something will not affect your app if you statically linked in the code of that dll
- code bloat, especially when you link to the c runtime statically. everyone has it, yet people still avoid the dll, filling megabytes upon megabytes of disk space with duplicate code.

2: poll question.

3: possibly; yes.

Share this post


Link to post
Share on other sites
Hi, ok question, I use devC++(mingw) and I link with the -l switch like
-lbla1 -bla2 etc..
These "blas" are references to .A files which I would think are static libraries, but most if not all of them require a .DLL to be in the windows/system folder in order for the program to run.. but So my question is, how can I tell how you are linking? Anyone know?
-DA

Share this post


Link to post
Share on other sites
look at the stuff inside .a file. i''m using msvc myself, but a .lib with code in it is very different from an import library.

Share this post


Link to post
Share on other sites
quote:
Original post by niyaw
- code bloat, especially when you link to the c runtime statically. everyone has it, yet people still avoid the dll, filling megabytes upon megabytes of disk space with duplicate code.



Do I have to LoadLibrary/FreeLibrary on the CRT? Or is there an easier way to do this?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
1) The benefits of DLLs:
* Easier updating. Customers can download updates measured in KB rather than MB.
* Allows for easier separation and reuse of components when needed. DLLs can be used in other applications, in other languages, in installs, etc.
* Gives runtime flexibility. Features can be implemented in DLLs and the application can expose these features at runtime based on the existence of those DLLs (such as plug-ins).

The benefits of static libraries:
* Debugging, profiling, bounds checking, etc. can sometimes be MUCH easier with LIBs than with DLLs because all of the relevant information gets bound to one entity.
* No need to worry about the complications of DLL interfaces. For example, it''s common to see people having problems with freeing memory in a DLL (or EXE) that was allocated in a different DLL (of course this is easy to solve but it still is a common problem).

2) I don''t see a problem with deriving in either case if it properly fits the design. However, I consider the major benefit of DLLs and LIBs to be the encapsulation of subsystems in a single unit. For this reason, I like the interfaces to be very strong and well defined. Derivation is, of course, a legitimate interface but I prefer something stronger like either C-style APIs or abstract classes (like COM interfaces).

2b) Going along with my aforementioned preference for C-style APIs or abstract classes, I view interface abstractions to be independent of implementation. The question of separating interfaces into libraries doesn''t particularly make sense to me since the interface abstractions that I prefer do not exist as physical machine code entities.

Share this post


Link to post
Share on other sites
quote:
Original post by antareus
Do I have to LoadLibrary/FreeLibrary on the CRT? Or is there an easier way to do this?


project settings->c/c++->code generation.

Share this post


Link to post
Share on other sites
quote:
Original post by niyaw
project settings->c/c++->code generation.

There is no entry for the single-threaded DLL version of the runtime.

[edited by - antareus on February 8, 2003 1:27:43 AM]

Share this post


Link to post
Share on other sites
Yeah thats where I was looking.

They have multi-threaded DLL versions but no single threaded DLL versions. Switch to multi-threaded DLL version and just stay in one thread the whole time?

Share this post


Link to post
Share on other sites
quote:
Original post by antareus
They have multi-threaded DLL versions but no single threaded DLL versions.


sorry, i missed the "dll" part. yes, there is no such thing as a single-threaded dll, so you''ll need to use multithreaded dll.
quote:

Switch to multi-threaded DLL version and just stay in one thread the whole time?

the c runtime doesn''t create any threads for itself. "multithreaded" in the c runtime just means that it''s thread-safe, that is, if a function in the c runtime is called from two or more threads simultaneously, nothing bad will happen. "singlethreaded" runtime provides no such guarantee. using multithreaded dll won''t create any new threads in your application unless you request so.

Share this post


Link to post
Share on other sites

  • Advertisement