命名空间 std 中的 C++ 互斥锁未命名类型答案

【问题标题】：C++ mutex in namespace std does not name a type命名空间 std 中的 C++ 互斥锁未命名类型
【发布时间】：2012-12-20 22:09:54
【问题描述】：

我正在编写一个简单的 C++ 程序来演示锁的使用。我正在使用codeblocks 和gnu gcc 编译器。

 #include <iostream>
 #include <thread>
 #include <mutex>
 using namespace std;
 int x = 0; // shared variable

 void synchronized_procedure()
 {
    static std::mutex m;
    m.lock();
    x = x + 1;
    if (x < 5)
    {
       cout<<"hello";
    }
    m.unlock();

 }

int main()
{

   synchronized_procedure();
   x=x+2;
   cout<<"x is"<<x;
}

我收到以下错误：mutex in namespace std does not name a type。

为什么会出现此错误？编译器不支持使用锁吗？

【问题讨论】：

如果你在 Windows 上，MinGW 还没有实现线程库。我去过那里并希望它有所不同，但至少 MSVC 可以正常工作。
哇，环顾四周，显然these 之一（仅限4.7）现在应该支持它。我目前正在下载一个来测试它，如果它最终可以工作，我会通知你。
好吧，这对我来说根本不起作用。我不知道你会不会有更好的运气。
哦，嘿。 This answer 确实有效！确保将-static 添加到链接器选项中。唯一的问题是我只能找到一个 GCC 4.7.0，这意味着放弃一些其他 C++11 特性，直到构建一个更新的特性。
mingw-w64 threads: posix vs win32的可能重复

标签： c++ multithreading compiler-errors locking mingw

【解决方案1】：

标准线程库的许多类都可以替换为 boost 类。一个非常简单的解决方法是用几行更改整个标准 mutex 文件。

#include <boost/thread.hpp>

namespace std
{
   using boost::mutex;
   using boost::recursive_mutex;
   using boost::lock_guard;
   using boost::condition_variable;
   using boost::unique_lock;
   using boost::thread;
}

并且不要忘记链接到 boost 线程库。

【讨论】：

这可能太多了，特别是如果你没有使用 boost
像这样扩展 std 命名空间会产生 UB。 en.cppreference.com/w/cpp/language/extending_std

【解决方案2】：

我碰巧遇到了同样的问题。 GCC 在 Linux 下与std::mutex 一起工作得很好。但是，在 Windows 上，情况似乎更糟。在 MinGW GCC 4.7.2 附带的头文件中（我相信你也使用了 MinGW GCC 版本），我发现 mutex 类是在以下#ifguard 下定义的：

#if defined(_GLIBCXX_HAS_GTHREADS) && defined(_GLIBCXX_USE_C99_STDINT_TR1)

很遗憾，_GLIBCXX_HAS_GTHREADS 未在 Windows 上定义。运行时支持根本不存在。

您可能还想直接在 MinGW 邮件列表上提问，以防 GCC 专家可以帮助您。

编辑：MinGW-w64 项目提供了必要的运行时支持。查看http://mingw-w64.sourceforge.net/ 和https://sourceforge.net/projects/mingw-w64/files/。另外，正如 0xC0000022L 所指出的，您需要下载 POSIX 线程版本（我上次没有提到）。

【讨论】：

事实证明，即使使用 MinGW64，您也必须使用后缀为 -posix 的 GCC 相关工具，而不是 -win32 ... 这显然是指使用的线程模型。

【解决方案3】：

Mingw-builds 工具链的“线程模型：win32”至少不支持互斥锁。您必须选择任何带有“线程模型：posix”的工具链。在尝试了几个版本和修订版（架构 i686 和 x86_64）后，我只发现 x86_64-4.9.2-posix-seh-rt_v3-rev1 中的支持是线程模型，IMO 是决定因素。

【讨论】：

【解决方案4】：

这现已包含在 MingW（版本 2013072300）中。要包含它，您必须在 MinGW 安装管理器中选择 pthreads 包。

【讨论】：

请提供系统信息，包括您的 MingW 版本，以便帮助他人
抱歉：Windows，mingw32-pthreads-w32 2.10-pre-20160821-1，这似乎是我们可以更新到的最新版本；还是说std::mutex does not name a type
谢谢@JohnPerry，我会看看是否有基于该版本的答案更新。

【解决方案5】：

我不知道它是否适用于所有人，但在其他方面你只需要更新你的 ndk。我正在使用 ndk-r11c，它运行良好。

【讨论】：

MinGW64 与 Android NDK 无关。
你说得对，重点是“11c”是相对于C版本的

【解决方案6】：

我通过以下步骤修复了它：

项目 > 构建选项...
默认选择的编译器：GNU GCC Compiler
在“编译器设置/编译器标志”选项卡上，检查选项 “让 g++ 遵循 C++11 ISO C++ 语言标准 [-std=c++11]”

【讨论】：

【解决方案7】：

我在使用 gcc4.7.7 时遇到了同样的错误。

加上“-std=c++0x”后，就固定了。

【讨论】：

如何添加？

【解决方案8】：

我在使用 MingW-W64 7.2.0 时遇到了同样的问题。我从mingw-64 download page 测试了几个不同的Windows 版本，发现MinGW-W64 GCC-8.1.0 支持mutex 并包含pthread 库。安装时，我选择了以下选项：

x86_64
posix
seh

我的基于 pthreads 的多线程代码现在可以在 Windows 和 Linux 上干净地编译和运行，无需任何更改。

这个版本比我使用的 7.3.0 版本更精简，因为它没有 CygWin 环境或包管理器。我还将mingw32-make.exe 复制到make.exe，这样就不需要修改我的Makefile。安装程序会在 Windows 开始菜单中创建一个“运行终端”链接。

【讨论】：

链接失效了
@NathanDai 已修复。

【解决方案9】：

对 MINGW 使用 POSIX 线程模型：

$ sudo update-alternatives --config i686-w64-mingw32-gcc
<choose i686-w64-mingw32-gcc-posix from the list>

$ sudo update-alternatives --config i686-w64-mingw32-g++
<choose i686-w64-mingw32-g++-posix from the list>

$ sudo update-alternatives --config x86_64-w64-mingw32-gcc
<choose x86_64-w64-mingw32-gcc-posix from the list>

$ sudo update-alternatives --config x86_64-w64-mingw32-g++
<choose x86_64-w64-mingw32-g++-posix from the list>

另请参阅：mingw-w64 threads: posix vs win32

【讨论】：

在 debian buster 上测试良好。这正是我所需要的。 -std=c++0x 解决方案现在已经过时，因为它现在是不必要的（至少从 gcc 8.3 开始）。
这似乎是正确的答案。

【解决方案10】：

我的 gcc 版本是 5.4，我在添加 #include 并在我的 CmakeLists.txt 中添加 -std=c++11 时解决了这个问题，如下所示：

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wall  -O3 -march=native -std=c++11")

【讨论】：

【解决方案11】：

我安装的是 Cygwin 而不是 WinGW。 youtube 上的说明 https://www.youtube.com/watch?v=DAlS4hF_PbY&t=245s

【讨论】：

欢迎提供解决方案链接，但请确保您的答案在没有它的情况下有用：add context around the link 这样您的其他用户就会知道它是什么以及为什么会出现，然后引用最相关的您链接到的页面的一部分，以防目标页面不可用。 Answers that are little more than a link may be deleted.