Open emfrias opened 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
Excellent, thanks!
I had to define _WEBSOCKETPP_CPP11_CHRONO_
instead of WEBSOCKETPP_CPP11_CHRONO
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.
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:
Here's the full error: