[Config] proposal of new macro, BOOST_DECL :follow up for boost::noncopyable & vc7.1 & dll
Hi Developers When using the boost.thread package as a dll under vc7.1, one gets for each reference of boost::mutex the C4275 warning for the inherited noncopyable class (in fact 5 times, one for mutex, one for timed_mutex, one for try_mutex, one for thread, and one for thread_group!!) c:\boost\include\boost-1_32\boost\thread\mutex.hpp(34) : warning C4275: non - DLL-interface 'boost::noncopyable_::noncopyable' used as base for DLL-interface 'boost::mutex' In order to avoid such warning, it would be nice to redefine -- again(sic) -- the BOOST_DECL macro and put it as a decorator for all dependent classes used by the boost libraries that could be generated as a dll.(thread, regex, filesystem, and so on). With the empty string as default value in boost/config.hpp, it would the responsability of each boost libraries to setup BOOST_DECL to the correct value when using it as a dll. Cheers Francis ANDRE
When using the boost.thread package as a dll under vc7.1, one gets for each reference of boost::mutex the C4275 warning for the inherited noncopyable class (in fact 5 times, one for mutex, one for timed_mutex, one for try_mutex, one for thread, and one for thread_group!!)
c:\boost\include\boost-1_32\boost\thread\mutex.hpp(34) : warning C4275: non - DLL-interface 'boost::noncopyable_::noncopyable' used as base for DLL-interface 'boost::mutex'
In order to avoid such warning, it would be nice to redefine -- again(sic) -- the BOOST_DECL macro and put it as a decorator for all dependent classes used by the boost libraries that could be generated as a dll.(thread, regex, filesystem, and so on).
With the empty string as default value in boost/config.hpp, it would the responsability of each boost libraries to setup BOOST_DECL to the correct value when using it as a dll.
Except we only have one definition for non_copyable, so what happens if library X wants it to have a dll interface and lib Y doesn't? It's also all inline, so declaring it imported is a little strange. Maybe some #pragmas to disable the warnings would be better, especially as we can't do much about: c:\data\boost\develop\boost\boost\thread\thread.hpp(75) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ] John.
Except we only have one definition for non_copyable, so what happens if library X wants it to have a dll interface and lib Y doesn't? It's also all
You'r right...so a solution could be to ask to the provider of each dll boost libraries to embed each declaration of an imported class with the followings win32 only pragmas #pragma warning(disable: 4275 4251) class BOOST_THREAD_DECL mutex : private noncopyable { //.... }; #pragma warning(default: 4275 4251) so that any missing __declspec(dllimport) in any user's dll library could be trapped as an error!! Francis -- A good friend will come bail you out of jail.......... but, a true friend....will be sitting next to you saying: "...that was fun." "John Maddock" <john@johnmaddock.co.uk> a écrit dans le message de news:01fe01c4c1a4$fd9e64f0$49f90c52@fuji...
When using the boost.thread package as a dll under vc7.1, one gets for each reference of boost::mutex the C4275 warning for the inherited noncopyable class (in fact 5 times, one for mutex, one for timed_mutex, one for try_mutex, one for thread, and one for thread_group!!)
c:\boost\include\boost-1_32\boost\thread\mutex.hpp(34) : warning C4275: non - DLL-interface 'boost::noncopyable_::noncopyable' used as base for DLL-interface 'boost::mutex'
In order to avoid such warning, it would be nice to redefine -- again(sic) -- the BOOST_DECL macro and put it as a decorator for all dependent classes used by the boost libraries that could be generated as a dll.(thread, regex, filesystem, and so on).
With the empty string as default value in boost/config.hpp, it would the responsability of each boost libraries to setup BOOST_DECL to the correct value when using it as a dll.
Except we only have one definition for non_copyable, so what happens if library X wants it to have a dll interface and lib Y doesn't? It's also all inline, so declaring it imported is a little strange. Maybe some #pragmas
to disable the warnings would be better, especially as we can't do much about:
c:\data\boost\develop\boost\boost\thread\thread.hpp(75) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ]
John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Francis ANDRE" <francis.andre@easynet.fr> wrote in message news:cmaonj$7o1$1@sea.gmane.org...
Except we only have one definition for non_copyable, so what happens if library X wants it to have a dll interface and lib Y doesn't? It's also all
You'r right...so a solution could be to ask to the provider of each dll boost libraries to embed each declaration of an imported class with the followings win32 only pragmas
#pragma warning(disable: 4275 4251) class BOOST_THREAD_DECL mutex : private noncopyable { //.... }; #pragma warning(default: 4275 4251)
so that any missing __declspec(dllimport) in any user's dll library could be trapped as an error!!
It has been suggested to me that it would be better (for other reasons) to mark individual member functions as exported rather than marking whole classes. Would that also help in this situation? I haven't looked closely yet, but if the individual member functions of the thread classes are exported then this warning may no longer be generated. Would there be any problems with changing to this approach? [snip]
Except we only have one definition for non_copyable, so what happens if library X wants it to have a dll interface and lib Y doesn't? It's also all inline, so declaring it imported is a little strange. Maybe some #pragmas
to disable the warnings would be better, especially as we can't do much about:
c:\data\boost\develop\boost\boost\thread\thread.hpp(75) : warning C4251: 'boost::thread_group::m_threads' : class 'std::list<_Ty>' needs to have dll-interface to be used by clients of class 'boost::thread_group' with [ _Ty=boost::thread * ]
Would exporting only the appropriate member functions help here as well? Mike
"Michael Glassford" <glassfordm@hotmail.com> writes:
It has been suggested to me that it would be better (for other reasons) to mark individual member functions as exported rather than marking whole classes. Would that also help in this situation? I haven't looked closely yet, but if the individual member functions of the thread classes are exported then this warning may no longer be generated.
Would there be any problems with changing to this approach?
Yes. It breaks some versions of GCC, which only work right if whole classes are marked. To get some inline functions in the same class, factor the class into base and derived parts, where the base class is exported. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
It has been suggested to me that it would be better (for other reasons) to mark individual member functions as exported rather than marking whole classes. Would that also help in this situation? I haven't looked closely yet, but if the individual member functions of the thread classes are exported then this warning may no longer be generated.
Would there be any problems with changing to this approach?
Is it supported by all compilers that use __declspec(dllexport)? What happens on 64-bit platforms, do we have different class layouts for exported and non-exported classes (like we used to on Win-16)? I'm assuming that there is some kind of logic for the warning being issued in the first place, or maybe not? John.
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:02c501c4c329$f3b9c4d0$38eb0352@fuji...
It has been suggested to me that it would be better (for other reasons) to mark individual member functions as exported rather than marking whole classes. Would that also help in this situation? I haven't looked closely yet, but if the individual member functions of the thread classes are exported then this warning may no longer be generated.
Would there be any problems with changing to this approach?
Is it supported by all compilers that use __declspec(dllexport)? What happens on 64-bit platforms, do we have different class layouts for exported and non-exported classes (like we used to on Win-16)? I'm assuming that there is some kind of logic for the warning being issued in the first place, or maybe not?
I'm afraid I don't currently know the answers to these questions. I was hoping someone else here would be able to answer questions like these. Mike
I've had to deal with this to some extent in the serialization library. I used decl export to guarentee the instantiation of code not referenced explicitly by name which some compilers will optimise out. (Its not clear to me whether or not this is standard conforming behavior). In any case I made a header boost/serialization/force_include.hpp which handles the legal combinations for the compilers I've been testing on. I had a lot problem with this and it seems to work - but I'm not really happy with it. Anyone who wants to comment on this is welcome to do so. Robert Ramey "Michael Glassford" <glassfordm@hotmail.com> wrote in message news:cmgiqh$2vu$2@sea.gmane.org...
"John Maddock" <john@johnmaddock.co.uk> wrote in message news:02c501c4c329$f3b9c4d0$38eb0352@fuji...
It has been suggested to me that it would be better (for other reasons) to mark individual member functions as exported rather than marking whole classes. Would that also help in this situation? I haven't looked closely yet, but if the individual member functions of the thread classes are exported then this warning may no longer be generated.
Would there be any problems with changing to this approach?
Is it supported by all compilers that use __declspec(dllexport)? What happens on 64-bit platforms, do we have different class layouts for exported and non-exported classes (like we used to on Win-16)? I'm assuming that there is some kind of logic for the warning being issued in the first place, or maybe not?
I'm afraid I don't currently know the answers to these questions. I was hoping someone else here would be able to answer questions like these.
Mike
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (5)
-
David Abrahams -
Francis ANDRE -
John Maddock -
Michael Glassford -
Robert Ramey