"Assignment operator could not be generated" warnings under MSVC 2005
Sorry about the cross-post to asio.user, it is a more general question.
I am receiving a number of warnings along the lines of the above when I
compile code using boost libraries. I see the warnings with
Boost.Variant, Boost.asio and others.
My code compiles, and appears to work fine, however, I am always nervous
about these kinds of warnings because I suspect there is something
waiting to bite me. I guess I am concerned as to what in my code is
causing the compiler to want to generate assignment operators.
Are these warnings symptomatic of a basic mistake I am making? I know
that you can't see the code, so this is only a general question. If
people think this might be a real problem, I am happy to try to make a
small code snippet to illustrate the problem.
Thanks for being there!
Kevin
Some examples:
Warning 3 warning C4512:
'boost::asio::detail::win_iocp_io_service::auto_work' : assignment
operator could not be generated;
c:\boost_1_34_1\include\boost-1_34_1\boost/asio/detail/win_iocp_io_service.hpp(574)
: see declaration of
'boost::asio::detail::win_iocp_io_service::auto_work'
c:\boost_1_34_1\include\boost-1_34_1\boost\asio\detail\win_iocp_io_service.hpp
588
Warning 9 warning C4512:
'boost::detail::variant::invoke_visitor<Visitor> with
[Visitor=boost::detail::variant::apply_visitor_binary_unwrap
Kevin Scarr
My code compiles, and appears to work fine, however, I am always nervous about these kinds of warnings because I suspect there is something waiting to bite me. I guess I am concerned as to what in my code is causing the compiler to want to generate assignment operators.
Are these warnings symptomatic of a basic mistake I am making? I know that you can't see the code, so this is only a general question. If people think this might be a real problem, I am happy to try to make a small code snippet to illustrate the problem.
The ASIO warning you're seeing is because the struct in question (auto_work) has a reference as a member. VC8/9 produce loads of similar warnings on Boost code. They cause a lot of noise, but don't seem to cause any real problems. I've raised some of the variant warnings @ http://svn.boost.org/trac/boost/ticket/1507. I've got a list of some ASIO warnings produced when running the regression tests with VC8/W4 that i havent got round to raising yet. I'll do that now while i think about it. Thanks, Richard Webb
Richard Webb wrote:
Kevin Scarr
writes: The ASIO warning you're seeing is because the struct in question (auto_work) has a reference as a member. VC8/9 produce loads of similar warnings on Boost code. They cause a lot of noise, but don't seem to cause any real problems.
Thanks, Richard I have tried to look into why the warnings were there on the principle that the warnings might be trying to, well, warn me about something. However, these warnings, and a few others, pretty much come in even with the simpler modules, so I have been working on the "noise" hypothesis. I know Chris has done some work with asio (I am only using 0.3.9 right now) to help with some warnings. I just downloaded 1.35 RC2 but I am not sure when I will be able to move to it. Thanks again for your help. Kevin
Richard Webb wrote:
Kevin Scarr
writes: My code compiles, and appears to work fine, however, I am always nervous about these kinds of warnings because I suspect there is something waiting to bite me. I guess I am concerned as to what in my code is causing the compiler to want to generate assignment operators.
Are these warnings symptomatic of a basic mistake I am making? I know that you can't see the code, so this is only a general question. If people think this might be a real problem, I am happy to try to make a small code snippet to illustrate the problem.
The ASIO warning you're seeing is because the struct in question (auto_work) has a reference as a member. VC8/9 produce loads of similar warnings on Boost code. They cause a lot of noise, but don't seem to cause any real problems.
Actually I'm pretty annoyed that these warnings are generated by the compiler at all: as far as I can see they can never represent a true programming error - though I stand to be corrected on that one! The warnings are raised when a class or structure does *not* have an explicit copy-constructor or assignment operator declared, *and* one could not be generated automatically by the compiler. However, the warnings are issued even though neither the copy-constructor nor the assignment operator are ever used - if they were used then you would get a compiler error. One possible fix is to declare but not define a private copy constructor and assignment operator (rather like boost::noncopyable), but given that those definitions are never used, this is just syntactic sugar to shut the compiler up. BTW if I remember correctly you get the same warnings if you declare a class that inherits from noncopyable which rather destroys the whole point of that one :-( Tellingly, as far as I know VC++ is the only compiler to issue this warning. HTH, John.
John Maddock wrote:
The warnings are raised when a class or structure does *not* have an explicit copy-constructor or assignment operator declared, *and* one could not be generated automatically by the compiler. However, the warnings are issued even though neither the copy-constructor nor the assignment operator are ever used - if they were used then you would get a compiler error.
I don't mind the errors, but it seems a warning about something not required is maybe a little over the top.
BTW if I remember correctly you get the same warnings if you declare a class that inherits from noncopyable which rather destroys the whole point of that one :-(
You are correct, you do. I tend to be asked to write programs which are largely user configurable within their application domain, so all my application classes tend to inherit from a base class which links the object to the user configuration (eg user names for objects, user descriptions, etc) so that all my user-messages are tailored for their configuration. Anyway, I always start with the base class inheriting from noncopyable because I really, really only want one instance of each of these objects -- many pointers to that instance is fine, but only one actual instance. Consequently, as you can guess, my compile output is littered with these warnings.
HTH, John.
Thanks for your comments! Kevin
On Sat, Mar 22, 2008 at 09:58:08AM -0000, John Maddock wrote:
Actually I'm pretty annoyed that these warnings are generated by the compiler at all: as far as I can see they can never represent a true programming error - though I stand to be corrected on that one!
The warnings are raised when a class or structure does *not* have an explicit copy-constructor or assignment operator declared, *and* one could not be generated automatically by the compiler. However, the warnings are issued even though neither the copy-constructor nor the assignment operator are ever used - if they were used then you would get a compiler error.
One possible fix is to declare but not define a private copy constructor and assignment operator (rather like boost::noncopyable), but given that those definitions are never used, this is just syntactic sugar to shut the compiler up. BTW if I remember correctly you get the same warnings if you declare a class that inherits from noncopyable which rather destroys the whole point of that one :-(
Tellingly, as far as I know VC++ is the only compiler to issue this warning.
How about writing a bug report for the compiler? Jens
One more reason I am glad OS X uses GCC ;-)
On Sat, Mar 22, 2008 at 6:07 AM, John Maddock
Jens Seidel wrote:
How about writing a bug report for the compiler?
Because it's a deliberate "feature"?
John. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (5)
-
Daniel Lord -
Jens Seidel -
John Maddock -
Kevin Scarr -
Richard Webb