From: williamkempf_at_[hidden]
Date: 2001-11-12 13:50:44
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- 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.)
Neither of which allows a C++ DLL (by the normal definition) to be
linked by different compilers. A C DLL or a COM DLL can, but a C++
DLL can't. However, your real point is in the following...
> 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.
In other words a C (or COM) DLL which is linked to a C++ module (DLL
or LIB).
I wasn't really trying to argue for a reason to require dynamic
linking to the C++ runtime to this extent. So I guess the quibling
is pointless.
> > 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 was about to argue that Boost.Threads is currently not a DLL and we
could retain the option for either type of linkage once I can get the
rest of the code into a single DLL. However, threadmon uses TLS and
it *must* be in a DLL regardless. I guess I don't know if this is an
issue. TlsAlloc/TlsFree are not part of the RTL and so the linkage
choice for the RTL seems irrelevant. I can also find no
documentation that would indicate problems in this regard. The real
concern with TLS here is cleanup of the data pointed to, but in
general this should be an obvious programming mistake.
> I think that statically linking Boost.Threads into a DLL is quite
dangerous.
I'd love to hear precise reasons why. Regardless, though, that's not
precisely what was being asked for.
Bill Kempf