zaphoyd / websocketpp

C++ websocket client/server library
http://www.zaphoyd.com/websocketpp
Other
6.97k stars 1.97k forks source link

VS2013 asio compile error #437

Open emfrias opened 9 years ago

emfrias commented 9 years ago

I'm getting a compile error with Visual Studio 2013 (Visual C++ 12), with boost 1.58, (on x86_64, probably not relevant).

What I see is boost::asio::steady_timer is using std::chrono::steady_clock, but websocketpp::lib::asio::milliseconds is returning a boost::chrono::milliseconds instead of a std::chrono::milliseconds, and MSVC is unable to convert it.

The CMakeLists.txt doesn't define _WEBSOCKETPP_CPP11CHRONO for me; if I explicitly define it, my problem goes away. I don't know if this is the right fix, or if it was left undefined for a reason.

Alternately, I could continue using boost::chrono but alter the definition of milliseconds like so:

          #if defined(BOOST_ASIO_HAS_STD_CHRONO)
            inline std::chrono::milliseconds milliseconds(long duration) {
                return std::chrono::milliseconds(duration);
            }
          #else
            inline lib::chrono::milliseconds milliseconds(long duration) {
                return lib::chrono::milliseconds(duration);
            }
          #endif

Here's the full error:

1>D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\memory(932): error C2664: 'boost::asio::basic_waitable_timerstd::chrono::steady_clock,boost::asio::wait_traits<Clock,boost::asio::waitable_timer_service>::basic_waitable_timer(const boost::asio::basic_waitable_timer> &)' : cannot convert argument 2 from 'boost::chrono::milliseconds' to 'const std::chrono::time_pointstd::chrono::system_clock,std::chrono::system_clock::duration &'
1> with
1> [
1> Clock=std::chrono::steady_clock
1> , WaitTraits=boost::asio::wait_traitsstd::chrono::steady_clock
1> ]
1> Reason: cannot convert from 'boost::chrono::milliseconds' to 'const std::chrono::time_pointstd::chrono::system_clock,std::chrono::system_clock::duration'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1> D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\memory(1003) : see reference to function template instantiation 'std::_Ref_count_obj<_Ty>::_Ref_count_objstd::reference_wrapper<boost::asio::io_service,boost::chrono::duration>(std::reference_wrapperboost::asio::io_service &&,boost::chrono::duration &&)' being compiled
1> with
1> [
1> _Ty=boost::asio::steady_timer
1> ]
1> D:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\memory(1003) : see reference to function template instantiation 'std::_Ref_count_obj<_Ty>::_Ref_count_objstd::reference_wrapper<boost::asio::io_service,boost::chrono::duration>(std::reference_wrapperboost::asio::io_service &&,boost::chrono::duration &&)' being compiled
1> with
1> [
1> _Ty=boost::asio::steady_timer
1> ]
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/transport/asio/connection.hpp(317) : see reference to function template instantiation 'std::shared_ptrboost::asio::steady_timer std::make_sharedboost::asio::steady_timer,std::reference_wrapper<boost::asio::io_service,boost::chrono::milliseconds>(std::reference_wrapperboost::asio::io_service &&,boost::chrono::milliseconds &&)' being compiled
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/transport/asio/connection.hpp(313) : while compiling class template member function 'websocketpp::transport::asio::connection::timer_ptr websocketpp::transport::asio::connection::set_timer(long,websocketpp::transport::timer_handler)'
1> with
1> [
1> config=fc::http::detail::asio_with_stub_log::transport_config
1> ]
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/transport/asio/endpoint.hpp(833) : see reference to function template instantiation 'websocketpp::transport::asio::connection::timer_ptr websocketpp::transport::asio::connection::set_timer(long,websocketpp::transport::timer_handler)' being compiled
1> with
1> [
1> config=fc::http::detail::asio_with_stub_log::transport_config
1> ]
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/transport/asio/endpoint.hpp(77) : see reference to class template instantiation 'websocketpp::transport::asio::connection' being compiled
1> with
1> [
1> config=fc::http::detail::asio_with_stub_log::transport_config
1> ]
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/endpoint.hpp(42) : see reference to class template instantiation 'websocketpp::transport::asio::endpointfc::http::detail::asio_with_stub_log::transport_config' being compiled
1> d:\code\graphene\graphene\libraries\fc\vendor\websocketpp\websocketpp/roles/server_endpoint.hpp(44) : see reference to class template instantiation 'websocketpp::endpointwebsocketpp::connection<config,config>' being compiled
1> with
1> [
1> config=fc::http::detail::asio_with_stub_log
1> ]
zaphoyd commented 9 years ago

this has been fixed on the develop branch already. The workaround for the current release version is to manually define WEBSOCKETPP_CPP11_CHRONO

emfrias commented 9 years ago

Excellent, thanks!

abdul-sami commented 9 years ago

I had to define _WEBSOCKETPP_CPP11_CHRONO_ instead of WEBSOCKETPP_CPP11_CHRONO

vadz commented 8 years ago

Defining _WEBSOCKETPP_CPP11_CHRONO_ means that our code can't use websocketpp::lib::condition_variable::wait_until() with the expressions constructed using types and functions from websocketpp::lib::chrono namespace which is rather unexpected, so I'm not sure if it's a really good idea to do this. Of course, we could also define _WEBSOCKETPP_CPP11_THREAD_ but then it's probably better to just use all C++11 features supported by the compiler which is, of course, an appealing solution but also increases the risk of writing code which doesn't compile with older g++ which still has to be used for some (embedded) platforms.

So my workaround for this currently is to define BOOST_ASIO_DISABLE_STD_CHRONO to make Boost::Asio use the same Boost::Chrono types as WebSocket++ does, but I think it would be a good idea to apply the patch from @emfrias in the original bug report to make it work out of the box.