12

Looking at C++ compiler support, it appears that the untimed version of std::shared_mutex is available in GCC 5.0+. However, even with gcc version 5.3.0 20151204 (Ubuntu 5.3.0-3ubuntu1~14.04), and compiling with -std=c++1z, a simple initialization of a shared mutex ends up with:

error: ‘shared_mutex’ in namespace ‘std’ does not name a type
        std::shared_mutex mutex_;

And no, I have already included the proper header: #include <shared_mutex>.

It can't locate the proper header, because it does not seem to exist. Actually, the linker uses the library locate at /usr/include/c++/5/shared_mutex, which contains only the implementation of the std::shared_timed_mutex (like the C++14 standard).

I have installed gcc-5 and g++-5 by adding the repository at ppa:ubuntu-toolchain-r/test and using update-alternatives to properly set up their bins.

Is there something I can do to compile my code correctly using the newest C++17 standard? And probably is a stupid question to ask, but is it too early to start using -std=c++1z even if it should be already supported? Because it is supported, right?

Piotr Skotnicki
  • 46,953
  • 7
  • 118
  • 160
alextoind
  • 1,143
  • 1
  • 13
  • 20
  • 4
    C++17 does not yet exist. Expecting to have implementations of features that do not yet exist and are not yet in a complete version of the language is... well, it kinda speaks for itself. – Nicol Bolas Mar 25 '16 at 15:34
  • Thanks @NicolBolas, I see. So the green marker in the link above is just smoke and mirrors, I guess. – alextoind Mar 25 '16 at 15:46
  • 1
    If you're open to [switching to a different standard library](http://libcxx.llvm.org/docs/UsingLibcxx.html#using-libc-with-gcc) implementation, [libc++ claims to have support for shared_mutex](http://libcxx.llvm.org/cxx1z_status.html). – Michael Mar 25 '16 at 15:47
  • 3
    According to [this resource](https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.201z), the implementation should be in trunk, not necessarily in gcc5 itself – Piotr Skotnicki Mar 25 '16 at 16:08
  • @NicolBolas it's legitimate to expect experimental implementation/support for features that have already been voted in, before the standard document is officially released in its final form – Piotr Skotnicki Mar 25 '16 at 16:29
  • Many thanks for the clarification @PiotrSkotnicki and for the suggestion, Michael: I'll check if it works as expected or I'll directly change approach. – alextoind Mar 25 '16 at 16:51
  • 5
    cppreference fixed. This was committed [well after](https://gcc.gnu.org/viewcvs/gcc/trunk/libstdc%2B%2B-v3/include/std/shared_mutex?revision=224158&view=markup) GCC 5.1's release, so there's no way it's going to be in the 5 branch. – T.C. Mar 25 '16 at 20:38
  • @T.C. I had already seen it yesterday, but I had no time to post it here. +1 for fixing the reference. – alextoind Mar 27 '16 at 09:04
  • you can use boost::shared_mutex instead of std::shared_mutex. – Protoss Apr 17 '16 at 05:12

2 Answers2

18

The confusion on cppreference was probably because std::shared_mutex really was added to GCC 5.0, in revision 200134. But that was the early incarnation of that type based on a C++1y draft. In fact it was the timed shared mutex, which was called std::shared_mutex at the time.

Before the final C++14 standard was published std::shared_mutex was renamed to std::shared_timed_mutex, and so before the GCC 5.1 release (which is the first release in the 5.x series) the type in libstdc++ was renamed, see revision 207964.

So although at one point during the GCC 5.x pre-release phase there was a std::shared_mutex type, it wasn't the C++17 untimed one, and it got renamed before appearing in any official release of GCC.

Then, during the development of the GCC 6.x release series the C++1z untimed shared mutex got added, reusing the std::shared_mutex name. That's the commit T.C. linked to in the comments above, revision 224158.

So the C++17 untimed shared_mutex was never in any GCC 5.x version. For a brief period before the first 5.x release there was a timed one called std::shared_mutex, but in all proper 5.x releases it's called std::shared_timed_mutex.

The first release to ship the C++17 untimed one was 6.1 in April 2016, so with any GCC release after that you can use std::shared_mutex (as long as you enable C++17 in the compiler, e.g. with the -std=gnu++17 or -std=c++17 flag).

GCC 5 was released in 2015, so expecting to be able to use C++17 with that version is a bit unrealistic. GCC 6.x and 7.x have pretty good C++1z support (but only based on the current drafts at the time of release, of course).

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • Thanks for the clarification. I've marked the answer as accepted even though it has been almost answered in the comments above. – alextoind Feb 17 '17 at 16:27
  • there is know answer, i have the include but it still saying error: ‘shared_mutex’ in namespace ‘std’ does not name a type, when i still have the include, so weird, long answer, no solution – Patrik Laszlo Mar 23 '19 at 16:09
  • 1
    @PatrikLaszlo did you actually read the answer? It explains that in GCC 5.x releases the `` header might only provide `std::shared_timed_mutex` and not `std::shared_mutex`. That was the whole point of the question: having the header doesn't mean you have the type. If you have GCC 6.1 or later and still get the error then it's probably because you're not telling the compiler to use C++17, try adding `-std=c++17` or `-std=gnu++17`. – Jonathan Wakely Mar 23 '19 at 16:10
  • OHHH! THANKS SO MUCH! WORKS RIGHT AWAY! I WAS ON C++11, now ON CMAKE: set(CMAKE_CXX_STANDARD 17) – Patrik Laszlo Mar 23 '19 at 16:13
  • 1
    Obviously if you want to use new type that was added in C++17 type then you need to use C++17. – Jonathan Wakely Mar 23 '19 at 16:14
0

follow this link to install/upgrade to the latest version of GCC and G++. http://tuxamito.com/wiki/index.php/Installing_newer_GCC_versions_in_Ubuntu

I have tried it on my ubuntu and successful.

uss
  • 1,271
  • 1
  • 13
  • 29
  • The question was posted before the final release of the C++17 standard. It's a nonsense now. – alextoind May 27 '19 at 16:15
  • A link to a solution is welcome, but please ensure your answer is useful without it: [add context around the link](//meta.stackexchange.com/a/8259) so your fellow users will have some idea what it is and why it’s there, then quote the most relevant part of the page you're linking to in case the target page is unavailable. [Answers that are little more than a link may be deleted](//stackoverflow.com/help/deleted-answers). – double-beep May 28 '19 at 11:32