Boost logo

Boost :

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-08-21 04:45:08

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:

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at