[boost] boost::noncopyable errors are difficult to diagnose on MSVC

Subject: [boost] boost::noncopyable errors are difficult to diagnose on MSVC
From: Zachary Turner (divisortheory_at_[hidden])
Date: 2009-11-06 12:44:43

Is there anything that can be done to improve the error messages generated
by the compiler when a copy fails to be made due to a boost::noncopyable?  I
had just finished a sprint where I had typed close to 1,000 lines of code
with tons of new classes and objects before trying to compile, and one of
the classes I had entered was similar to the following:

class foo
{
public:
   foo(boost::asio::ip::tcp::socket& socket)
      : socket_(socket)
   {
   }

private:
   boost::asio::ip::tcp::socket socket_;
};

Problem here is that I forgot to add a reference to the class member, it was
by value so the compiler is going to generate an error since a socket cannot
be copied.  The error this generated from the compiler was:

1>Q:\include\boost\1.39.0\boost/asio/basic_io_object.hpp(92) : error C2248:
'boost::noncopyable_::noncopyable::noncopyable' : cannot access private
member declared in class 'boost::noncopyable_::noncopyable'
1>        Q:\include\boost\1.39.0\boost/noncopyable.hpp(27) : see
declaration of 'boost::noncopyable_::noncopyable::noncopyable'
1>        Q:\include\boost\1.39.0\boost/noncopyable.hpp(22) : see
declaration of 'boost::noncopyable_::noncopyable'
1>        This diagnostic occurred in the compiler generated function
'boost::asio::basic_io_object<IoObjectService>::basic_io_object(const
boost::asio::basic_io_object<IoObjectService> &)'
1>        with
1>        [
1>
 IoObjectService=boost::asio::stream_socket_service<boost::asio::ip::tcp>
1>        ]

The most I can possibly figure out from this is that it's related to a
socket.  but this hardly helped as I had been using socket stuff all over
the place.  It took a long time to track this down because there was zero
information about even what source file the offending code was in.  I know
this is sort of catering to the compiler, but is there any trickery that can
be done so that at least the compiler generates an error related to the
source file the object was declared in?