On Sat, Aug 04, 2012 at 10:59:18AM +0400, Vladimir Prus wrote:
On 03.08.2012 21:53, Robert Ramey wrote:
BUT the dll created, as well as the serialization library used have been created with static linking.
Do you mean static runtime linking? By definition, dll cannot use static linking.
I'm assuming that the file system library is also created this way. I "think" this should be OK even though some C++ runtime code will be repeated between the DLL and the mainline test components and that this might create a problem so it's probably not the best practice. Never the less, users do this and I want to test it.
I believe that using static runtime from DLL, is something that should never, ever, be done. On Linux, it was possible years ago via tricky command line options, but is no longer possible. On Windows/MSVC, this may be still possible, but unless I am entirely wrong, this is extremely risky practice that should not be promoted.
So, unless some MSVC expert steps in and proves me wrong, I think this is not use case that need to be supported or tested for in the first place.
In the Boost case, no, there's no real use case for disjoint runtimes in different modules. In the real world, less so. It is perfectly sound to have dynamic libraries built with different runtimes as long as you're aware that you may never share any built-in C++ or C types across the module boundary, and make sure that anything you allocate in one module, you destroy with the functions in that module. A very common use case for such a thing is plugin architectures for applications that have enough of a legacy baggage to have it's own "standard library"-like library implemented, with cross-module safe types. I write such code all the time. Like anything else, it's about recognizing the restrictions and limitations you have in a situation, but saying it's "by definition" is doing a disservice as it _isn't_ impossible, it's just very cumbersome. -- Lars Viklund | zao@acc.umu.se