Roland Schwarz <roland.schwarz <at> chello.at> writes:
I inadvertently replied to the wrong posting.
John Maddock wrote:
That's your problem: there must be one single rtl shared both by your code and the Boost.Threads dll: and that means using the dynamic C runtime.
That surprises me somewhat. Explicitely:
mydll depending on dynamic CRT.
myapp depending on static CRT and depending on mydll.
You think this is not possible? Just tried it. Found no obvious problem. Are there hidden traps?
This is an old-time problem MSVC programmers keep stumbling upon. As John points out, the only safe alternative is that every executable (EXE or DLL) in an app uses the same *dynamic* version of the CRT: all of them debug dynamic or all of them release dynamic. Every other option will casue you trouble. The biggest source of incompatibilites has to do with memory allocation. MSVC malloc/free (and new/delete) implementation uses an internal heap allocated at CRT initialization time. Every instance of the CRT has its own internal heap. Now, if module (EXE or DLL) A allocates some memory and module B tries to free it through another copy of the CRT, an instant crash is guranteed, because the memory does not belong in B's internal heap. Try it: select static CRT for every module, allocate some memory in your EXE and let some DLL try to free that memory. When everybody selects dynamic CRT, there's only one copy of it across the app, and you'll find no problem. If you restrict yourself to C-style calls where no ownership of memory is transferred, then everything is OK, but this is hardly possible in Boost libraries where C++ objects are passed around. In the case where the boundary between the EXE and the DLL is crossed only by object *pointers*, the problem still remains if a module tries to delete a pointer not allocated within its CRT, but in this case there's a simple workaround: if the class being pointed to has a virtual destructor, then it is safe to delete a pointer everywhere, since the destruction code, being virtual, will get executed within the module where the object was created (as the vtable will be pointing to that module). Hope this sheds some light on the issue. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo