Re: Boost Jam question: how to set "features"?

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