Vs2019 16.3.1 appears to remove std::tr2::sys in platform toolset v142, breaking Cinder 0.9.1 - and how to solve it

Hey Embers,

As the title states, it would appear that the latest vs2019 update finally removes the deprecated std::tr2::sys namespace, which Cinder 0.9.1 relies on for its path. I’ll see if I can possibly figure out how to update this and provide a fix that allows anyone to still use Cinder 0.9.1 alongside the v142 toolset, but last time I tried replacing std::tr2::sys with something more contemporary, lots of other things broke.

So if anyone runs into the same issue as me I’d recommend simply stepping down to v141 (the Vs2017 toolset). I’ll be doing that myself if I can’t figure out how to fix things.

Cheers,
Lasse

Hey again,

Here are two solutions to the problem stated above, for Windows.

If you’re anything like me, you prefer moving forward, rather than backwards. Thanks to the VsTeam deprecating std::tr2::sys (with admittedly a lengthy forewarning) you’ve got a tough choice to make.

You can either…

  1. Downgrade to the v141 Toolkit (ala Visual Studio 2017), or…
  2. Risk a bit of experimental behavior and upgrade a few things (which will happen eventually, regardless).

If your work has any real commercial deployment connected with it, go for Option 1. Otherwise, read on for option 2 and how I opted to upgrade.

  1. Get Cinder 0.9.2dev with vs2019 sln in this specific pull/commit
  2. In Filesystem.h, change
namespace fs = std::experimental::filesystem;

to

namespace fs = std::filesystem;
  1. In TwMgr.cpp, insert:
#define _HAS_AUTO_PTR_ETC 1
  1. Grab Boost 1.71 in the 14.2 version with appropriate platform 32/64 bits
  2. Copy in the boost headers into include/boost where you put the Cinder sln
  3. Set the Language Standard in the project properties to ISO C++17 Standard (std:c++17)

You should now have a new and compilable version of CinderLib 0.9.2-dev.

Cheers,
Gazoo

Interesting, thanks for posting this. Will try tomorrow and update my PR appropriately.

Was upgrading boost necessary because you upgraded the Language Standard to C++17? I didn’t do this yet, planning to test it out after I get through my current project (a couple weeks).

cheers,
Rich

My pleasure @rich.e :slight_smile:

I can’t give you an exact answer re. Boost. All I can tell you is I had version 1.60 that I was actively using with Cinder 0.9.1 when things went side ways. While compiling cinder 0.9.2dev, I recall definitely trying to just copy over the headers and libraries from boost 1.60 and that not working immediately.

I don’t recall what exactly the problem was, but I’d reason it was significant because it prompted me to apparently move forward with trying to use boost 1.71 to see if it solved the issues. Which it would appear it did.

Boost 1.60 conflicting with C++17 wouldn’t surprise me.

Hope that helps.

Cheers,
Gazoo

I can confirm that std::experimental::filesystem is no longer available after the 16.3.1 update, so if you want to use v142 then we’re forced to switch to C++17. Not a bad thing I suppose, it was going to happen anyway.

I updated my branch / PR with to build with latest, C++17 enabled, so far so good. I didn’t update boost, the only thing I saw that required it was the legacy ci::JsonTree class, which we’ve decided to remove for the release after next (see post here), so I just went ahead and removed it from the vc2019 project file and everything else built fine. As far as I can tell, we have no more boost dependencies on Windows, which is a long term goal that we’re finally reaching.

1 Like