Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-12 13:35:58

From: <williamkempf_at_[hidden]>
> --- 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
> not
> > > 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
> which
> > compiler has been used to build them.
> Which is simply not possible with C++. C++ DLLs are compiler
> specific.

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
C++ runtime.

> 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, gregod at, cpdaniel at, john at