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
> > not
> > > > inherently unsafe
> > >
> > > ... and is sometimes the only option when the DLL and the EXE
> > built by
> > > different compilers. DLLs are supposed to "just work"
> > 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
> effectively forced by MS to share a common calling convention
> 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
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
> > Yes, but not all applications will use both DLLs and an EXE that
> > TLS. This was my reasoning initially as well, but I'm being
> > to at least let the user shoot themselves in the foot here.
> Yes, but if Boost.Threads uses TLS internally (to maintain thread-
> data) this will affect users even when they don't use TLS
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
I'd love to hear precise reasons why. Regardless, though, that's not
precisely what was being asked for.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk