From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 13:35:58
> --- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> > From: "Steve Anichini" <sanichin_at_2...>
> > > Hence why I'm lobbying that a) linking with the static runtime is
> > > inherently unsafe
> > ... and is sometimes the only option when the DLL and the EXE are
> built by
> > different compilers. DLLs are supposed to "just work" regardless of
> > compiler has been used to build them.
> Which is simply not possible with C++. C++ DLLs are compiler
True in general, but with a little care it's possible. Windows compilers are
effectively forced by MS to share a common calling convention (__stdcall)
and a common vtable layout (COM.)
Imagine a DLL that has a very simple API, something like
void __stdcall startup();
void __stdcall print(char const *);
void __stdcall shutdown();
and uses Boost internally. I see no reason to require dynamic linking to the
> Yes, but not all applications will use both DLLs and an EXE that use
> TLS. This was my reasoning initially as well, but I'm being swayed
> to at least let the user shoot themselves in the foot here.
Yes, but if Boost.Threads uses TLS internally (to maintain thread-specific
data) this will affect users even when they don't use TLS themselves.
I think that statically linking Boost.Threads into a DLL is quite dangerous.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk