On Wed, May 19, 2010 at 3:34 PM, James Mansion <james@mansionfamily.plus.com> wrote:
John Maddock wrote:
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++. 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 :-(
Just thinking out loud yours, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMQP changed to decorating the methods themselves (and only the ones designed for consumption outside the module) for reasons similar to this. Suggest you talk to Steve Huston, or search the AMQP mail list archive.
We have a very minor problem that apparently can be fixed by the introduction of one new config macro and will have very little impact on most Boost libraries. I'd hate to do anything that forces massive changes like decorating every member. Particularly if the only practical problem users are running into is failing to catch a library's exceptions when thrown by GCC across a DSO/DLL boundary. --Beman