VS 2017 program not recognizing “scoped_lock”

Question

I've been having issues using scoped_locked in VS 2017. I believe I traced them back to the <mutex> declaration, copied below. What would be the safest way to disable the #if switch at the beginning to gain use to scoped_lock? Thanks again.

#if _HAS_CXX17
// CLASS TEMPLATE scoped_lock
template<class... _Mutexes>
class scoped_lock
{   // class with destructor that unlocks mutexes
public:
    explicit scoped_lock(_Mutexes&... _Mtxes)
    : _MyMutexes(_Mtxes...)
    {   // construct and lock
    _STD lock(_Mtxes...);
    }

    explicit scoped_lock(adopt_lock_t, _Mutexes&... _Mtxes)
    : _MyMutexes(_Mtxes...)
    {   // construct but don't lock
    }

    ~scoped_lock() _NOEXCEPT
    {   // unlock all
    _For_each_tuple_element(
        _MyMutexes,
        [](auto& _Mutex) _NOEXCEPT { _Mutex.unlock(); });
    }

    scoped_lock(const scoped_lock&) = delete;
    scoped_lock& operator=(const scoped_lock&) = delete;
private:
    tuple<_Mutexes&...> _MyMutexes;
};

Answer 1

From your question it is not clear if you want to disable/enable this behavior. But in general this can be controlled with the /std:c++latest compiler argument and/or overriding _HAS_CXX17 as stated in the Visual C++ Team Blog. The issue is that without ovverides the _HAS_CXX17 is defined depending on the compiler version in yvals.h (see this question) and thus this may vary depending on the version of Visual Studio (so I can't give you a straighforward answer what combo will give you the needed result since it is not clear whether you want to disable/enable it, and what is your exact Visual Studio version). As mentioned in the article, this has the downside that you may loose other features, since they did not provide a fine grained control over the STL. But you can try and see if reverting to the old STL behavior causes issues for you.