On Wed, May 19, 2010 at 11:56 AM, John Maddock <boost.regex@virgin.net> wrote:
FYI, there is an open ticket on this: https://svn.boost.org/trac/boost/ticket/2114 which still requires some work (mostly tests and updated docs) before rolling out.
As Jürgen points out, that's one of the three or four open tickets we are trying to resolve.
...
If you use BOOST_SYMBOL_EXPORT, VC++ will warn because __declspec(dllexport) isn't valid in this context. If you don't decorate my_exception at all, VC++ is happy, but GCC shared libraries compiled with -fvisibility=hidden can't successfully throw exceptions up to callers outside the shared library. The only way around that I can see is to use a separate macro that is only defined for GCC.
Yeh, that's a tricky one, 'cos VC++ will warn almost whatever you do. I *think* the correct thing to do for header only classes is to mark them as __declspec(dllimport) - that way if you contain or inherit from them in an exported class you won't get more warnings - the main culprit here is noncopyable which is unusable without copious warnings from VC++.
I've tried VC++ with __declspec(dllexport), __declspec(dllimport), and BOOST_SYSTEM_DECL (which will be __declspec(dllexport) or __declspec(dllimport) depending on the context. Surprisingly, __declspec(dllexport) is the only decoration that passes all Boost.System tests. But all of the decorations tested produce VC++ warning messages.
Oh and I think I've had warnings when containing a shared_ptr in an exported class too... in fact come to think of it if I write an exported class like this:
class BOOST_SYMBOL_EXPORT foo { private: some_boost_type member; };
Won't I have issues unless "some_boost_type" is declared visible/exported? Bare in mind that this could be practically any template declared in Boost :-(
While I didn't run into that particular problem, Boost.System has minimal needs. One of the advantages of introducing a separate macro is that it won't be present for most compilers, including VC++. Thus only GCC will actually get any decoration, so there will be no warnings or other unintended consequences for other compilers. --Beman