On 21/08/2018 15:35, degski wrote:
This is why you're always encouraged to link to the runtime library as shared -- because since it's a dependency of every other library, the only time it's safe to use it statically is if you don't use *any* shared libraries at all. Otherwise you end up with multiple copies of the runtime, and thus multiple separate heaps, and hilarity ensues.
This is I think not what happens in practice, in vcpkg f.e. creation of a static library will by default also imply that that library is statically linked to the run-time. I also do this when building Boost, while you are actually saying that that option/possibility should not even exist as I presume that the combination of a dynamic library statically linked to the run-time crt makes even less sense.
I've never used vcpkg, so I can't really speak to its choices, but whenever you create a new project in VS (regardless if it is an executable, static library, or dynamic library), it will select the dynamic CRT by default, because this is the safest choice in all cases. And a cursory glance at the vcpkg repository shows that this script: https://github.com/Microsoft/vcpkg/blob/961cd9effd9a5230f211875bb0e9a6773e0e... attempts to prevent you compiling a dynamic library while linking to the static CRT. (I don't know how well it is actually applied; perhaps I'm misreading something.) As I said before, there is no problem with linking to the static CRT if you are *only* using static libraries. There is also less problem if you are only using DLLs that practice strict memory segregation (eg. using an agreed memory allocator for all exchanged objects, such as the COM or Shell allocators), or ensuring that objects are only ever allocated or deallocated on exactly one "side". It's a lot harder (though not impossible, with very careful use of smart pointers and allocators) to achieve this segregation with C++ libraries. (Having said that, this only discusses one aspect of library duplication, that of separate heaps. There can be other issues such as duplicate singletons and other statics; these can also ruin your day, but are more library-specific.) Other "shared" CRT state (locale, exceptions, standard I/O streams, etc) also won't actually be shared if you are using multiple static CRTs.