|
Boost : |
From: Schaible, Joerg (Joerg.Schaible_at_[hidden])
Date: 2000-10-20 06:57:16
Hi Csaba,
> Would not the example still hold without any reference to
> shared_ptr?? (see
> code below)
The code was not meaningful in any way, it was just to demonstrate the
situation.
> Conclusion is not to export classes with template members -
> yes, I'd expect
> this behavior given the limits of DLLs anyway.
This is a compiler issue. Basically it should *not* matter, whether I put my
library into a DLL (or shared lib) or not. For DLL's this is challenge for
the compiler vendor, but not unresolvable.
> I would never
> try to export
> *any* templates from a DLL:
>
> 1) the MSVC compiler seems to require to see all the template
> code when it
> needs to instantiate one
> 2) the MSVC compiler requires that "exported" template code
> go to headers
> (exporting of template stuff is not supported)
This is no real limitation caused by building a DLL. IMHO there are not very
much compilers around that support templates without seeing their full
implementation. If a compiler support "extern template" it is not far away
form supporting exports from a DLL, too.
> Also, DLLs are limited in a number of other ways (i.e.,
> memory allocation
> should consistently happen within the DLL xor the client).
Sorry. This is not true. You should just allocate/free the memory from the
same manager independent where the code lives. But this is true for all kind
of memory management in applications and libraries.
> Best to think of Win32 DLLs as being invented for C.
I've build C++-DLL's and shared libraries for Windows, OS/2 and Unix
flavours for more than 8 years. I've never detected that ANSI-C describes
any library technology.
Greetings,
Jörg
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk