Multithreaded DLL

Here''s the rule of thumb: if you''re going to use DLLs use the DLL version of the runtime. If you statically link with the runtime then the DLL and the executable are going to hold different copies of the variables that belong to the runtime. This includes different memory heaps (which seems to be the number one problem for people new to DLLs) to different synchronization variables for IO streams (annoyingly hard to track down and debug if you don''t know what you''re looking for) to separate locale information. This duplication can either be just wasteful (having mutiple copies lying around eats up memory) or it can be the source of subtle and annyoing headaches.

Prime example: the code you have allocates an object in the DLL. If the DLL is built against a static version of the runtime, then the code that deletes the object must be in the DLL. If you call delete in the executable, the memory deleted would be one that the heap doesn''t own, which will cause a runtime error in debug mode. And who knows what''ll do in release.

You could still, in theory, link both the executable and the dll against static versions of the runtime. However, then you need to maintain very careful programmer discipline about which functions you can call from the exe and which functions you need to call from the dll. To be honest, it''s not worth the headache. You''ve already got plenty of things that can go wrong when working with dlls that you don''t need to go courting more.

It's just that. One is sued to save space (DLL), and one is used to make it portable (.lib).

// Edit: SiCrane beat me to it

[edited by - Newfound Ajarn on February 1, 2004 10:38:24 PM]

Great! Thanks for clearing that up SiCrane!
Arjan:
By not portable, you mean that if you want to make sure that it works you need to redistribute the runtime dll''s with your application to ensure they have the correct version?