Verify usability with Visual Studio 2015

[ecorm]

Verify that the library can be used with Visual Studio 2013. Identify, if necessary, the C++11 features that would need to be worked around to support VS2013.

[estan]

Perhaps Appveyor could come in handy here? I have a Windows 7 + MSVC installation in a VirtualBox machine, licenses for which I got through my schools MSDNAA subscription. I seldom boot it up though, and I'm not sure which MSVC version I currently have on there.

[taion]

Perhaps target VS2015? 2013 really is missing a lot of C++11 features (like constexpr...)

[taion]

I will need to do this eventually, FWIW, but I'm focusing on just OS X first.

[ecorm]

Perhaps Appveyor could come in handy here? I have a Windows 7 + MSVC installation

I can install Windows on VirtualBox easily enough, that's not the problem. The problem is lack of time to fix the inevitable deluge of VS compile errors. We don't use Windows in our project, so it's not a high priority for me.

Perhaps target VS2015? 2013 really is missing a lot of C++11 features (like constexpr...)

Yeah, VS2015 might be better. I'm not too keen on having the code littered with #ifdefs..

I will need to do this eventually, FWIW, but I'm focusing on just OS X first.

You did an excellent job with the OS X fixes. Feel free to tackle VS2015.

I might reject a VS2013 pull request if it ends up being a complete #ifdef mess. Maybe it's better that I tackle VS2013 so that I don't waste anyone's time.

[taion]

To clarify, assuming I can get away with it, I'd target VS2015 and hopefully not have to do too much work. I agree that fixing things for VS2013 would be really nasty and should be avoided. This isn't fully under my control from our side, though.

[estan]

I can install Windows on VirtualBox easily enough, that's not the problem. The problem is lack of time to fix the inevitable deluge of VS compile errors. We don't use Windows in our project, so it's not a high priority for me.

Yep, not a priority for us either. Since I came across the issue, I just wanted to drop the link to Appveyor in case you didn't know about it. Might be nice for CI, if someone shows up that has a real need for Windows. I'd also be all for going for VS 2015 unless someone yells high about it.

[ecorm]

VS2013 does not support unrestricted unions, and that is a huge deal breaker for me. The library revolves around wamp::Variant, which in turn revolves around unrestricted unions.

VS support will have to be for VS2015, at the very least.

[taion]

Looks like VS2015 will support everything in C++11 except for expression SFINAE: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx

Hopefully won't be too bad to add support, then.

[ecorm]

I don't remember using expression SFINAE anywhere, so hopefully, we're in the clear.

[taion]

VS2015 is out now: http://blogs.msdn.com/b/somasegar/archive/2015/07/20/visual-studio-2015-and-net-4-6-available-for-download.aspx

[taion]

We dropped Windows support from our requirements, so I'm no longer planning on working on this issue.

[ecorm]

I'll eventually try to look into this myself, if nobody else volunteers.

[KrishnaPG]

Here are few errors/warnings on the VS2015 to start with:

1>------ Build started: Project: cppwamp, Configuration: Debug Win32 ------
1>cl : Command line warning D9002: ignoring unknown option '-std=c++11'
1>  cppwamp.cpp
1>\cppwamp\include\cppwamp\./internal/options.ipp(66): warning C4346: 'ValueTypeOf<`template-type-parameter-1'>': dependent name is not a type
1>  \cppwamp\include\cppwamp\./internal/options.ipp(66): note: prefix with 'typename' to indicate a type
1>\cppwamp\include\cppwamp\./internal/options.ipp(66): error C2061: syntax error: identifier 'ValueTypeOf<`template-type-parameter-1'>'
1>\cppwamp\include\cppwamp\./internal/options.ipp(80): error C2143: syntax error: missing ';' before '{'
1>\cppwamp\include\cppwamp\./internal/options.ipp(80): error C2447: '{': missing function header (old-style formal list?)
1>\cppwamp\include\cppwamp\internal\variantbuilder.hpp(38): warning C4800: 'wamp::Variant *': forcing value to bool 'true' or 'false' (performance warning)
1>\cppwamp\include\cppwamp\internal\variantbuilder.hpp(39): warning C4800: 'wamp::Variant *': forcing value to bool 'true' or 'false' (performance warning)
1>\boost_1_60_0\boost/asio/detail/socket_types.hpp(24): fatal error C1189: #error:  WinSock.h has already been included

Hope someone can give workarounds.

[ecorm]

Thank you, @KrishnaPG. I'll eventually install VS2015 on a Windows machine (or VirtualBox), and will attempt to fix these errors. I'm very busy at work at the moment.

[michaelaeriksen]

Any update on Visual Studio 2015 support?

[ecorm]

@michaelaeriksen, no one has stepped up with a pull request yet. I've been meaning to add support for the latest VS2015, but haven't had the time yet. I can't really give you an ETA. :-(

[michaelaeriksen]

I managed to compile with VS2015, but I had to comment out most of the variant visitors I also had to fix all the ArgTraits. Basically VS2015 does not like any of the Metafunctions. It would be nice if someone with more understanding of template meta programming would take a look!

[ecorm]

@michaelaeriksen, it's reassuring to know that it's only the metafunctions causing grief in VS2015! I can't promise anything, but I'll try installing Visual Studio and taking a look this weekend.

[ecorm]

I've set-up VS2015 on my Windows machine. Probably won't have time to resolve the compiler errors this weekend, but at least the tools are now set-up.

[michaelaeriksen]

Make sure you have VS2015 Update 3 installed.

I also had to add this

        case (int) TransportErrc::aborted:
        {
          if (code.value() == 995) // WSA_OPERATION_ABORTED
          {
            return true;
          }
//          return code == std::errc::operation_canceled;
        }

in bool TransportCategory::equivalent to get the tests to work.

[ecorm]

I've managed to get CMake to generate a VS project, and I've started tackling the compile errors. Most of the problems seem to occur when constexpr is used with SFINAE. This is a known VS bug. I'll try changing my metafunctions to avoid constexpr and instead use old-school traits à la:

struct IsBlue
{
    static const bool value = expression;
}

[michaelaeriksen]

Is the VS2015 port finished?

[ecorm]

Sorry, no. Too busy with summer stuff. I can't give you an ETA either.

I was going to try abandoning SFINAE and use a tagged-dispatching approach instead.

[michaelaeriksen]

Bummer, I would really like to use your library! In my hacked version I have an issuer where Blobs are decoded as strings.

I have a simple pub like this

    Variant v;
    v = Blob{ 0x12, 0x34, 0x56 }; // Assign a binary object of 3 bytes
    publisher->publish(Pub("str.num").withArgs(v), yield);

And the sub

    subscriber->subscribe(Topic("str.num"), std::bind(&onDynamicEvent, std::placeholders::_1), yield);

  void onDynamicEvent(Event event)
  {
  ...
  }

The type of the event Payload._args is string where I'm expecting it to be Blob.

[michaelaeriksen]

Just confirmed it work if I use

  auto tcp1 = connector<Json>(iosvc, host);

but fails if I use

  auto tcp1 = connector<Msgpack>(iosvc, host);

[KrishnaPG]

@michaelaeriksen Is it working with VS2015? Have been waiting to make it work as embedded lib.

[michaelaeriksen]

Yes, I managed to get most of it to compile with VS2015, but there is still a few issues and I'm not sure if they only exists in my build.

[michaelaeriksen]

Looks like my wamp::Blob issue is not with cppwamp but crossbar.io. I just updated my windows version of crossbar.io to 0.15.0 and now Blobs are encoded and decoded correctly with Msgpack!

[ecorm]

Looks like my wamp::Blob issue is not with cppwamp but crossbar.io. I just updated my windows version of crossbar.io to 0.15.0 and now Blobs are encoded and decoded correctly with Msgpack!

That's good to hear, @michaelaeriksen.