Re: Exporting CString from a DLL
On Fri, 29 Feb 2008 10:54:57 -0500, "EricW" <empty@empty.com> wrote:
Hi All,
Thanks for the feedback. While I did get it to work (yes, by modifying
atlstr.h, ick) I'm going to back off of it for many of the reasons you
pointed out and try the stdafx.h approach. I've never changed a standard
header file to fix a problem and I don't want to start now. If you happen
to know anyone on the compiler team and can give them a nudge to smooth out
STL and DLL interaction that would be great,... yeah, I know I'm dreaming
there :).
Thanks again,
Eric
There haven't been any problems with STL and DLLs since VS.NET 2002, or
even VC6 after applying the Dinkumware patches. I'm really perplexed by
this documentation you found. I would have thought that MFC would dllexport
the most frequently used specializations of CString on char and wchar_t
anyway. What happens if you do nothing at all to "fix" things?
It seems to me that the "auto-exporting" of template base classes
introduced in VC7 to avoid the usually pointless C4275 warning has caused
nothing but problems while "solving" problems that simply do not arise if
you follow these rules for sharing C++ classes and objects across module
boundaries:
1. Link all participating modules to the same CRT DLL. This way, they share
the same heap, file descriptors, and most other CRT state.
2. Treat it as equivalent to static linking WRT things like compiler
version, compiler options, compilation dependencies, and so forth.
3. Don't use templates that have static data without explicitly
instantiating and dllexporting the specializations you use.
Following these rules will allow you to compose programs from DLLs and use
the classes they define as real C++ classes instead of COM-like interfaces.
I don't see how the auto-exporting of template bases does anything useful,
because you can't control precisely which module exports them. I mean, you
can still easily end up with multiple copies of a template specialization
when more than one DLL uses it, which is not a problem if you follow the
rules above; in particular, auto-exporting doesn't solve (3). IIRC, the
real goal was to suppress C4275, but it's always been possible to suppress
C4275 with #pragma warning(disable), which is fine to use, along with
suppressing C4251, if you follow these rules.
--
Doug Harrison
Visual C++ MVP