C++ mutex dans l'espace de noms std n'est pas le nom d'un type de

Je suis en train d'écrire un simple programme en C++ pour illustrer l'utilisation de verrous. Je suis à l'aide de codeblocks et gnu gcc compilateur.

 #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;
}

J'obtiens l'erreur suivante: mutex in namespace std does not name a type.

Pourquoi j'obtiens cette erreur?
N'est pas le compilateur en charge l'utilisation de verrous?

Si vous êtes sur Windows, l'enfilage de la bibliothèque n'est pas mis en œuvre par MinGW encore. J'ai été là et a souhaité qu'il soit différent, mais au moins MSVC a ce travail.
Wow, en regardant autour, apparemment, un des ces (4.7) devrait maintenant avoir un support. Je suis en train de télécharger l'un pour le tester et je vous tiens au courant si il finit de travailler.
Eh bien, ça ne marche pas du tout pour moi. Je ne sais pas si vous auriez plus de chance.
Oh, hé hé. Cette réponse effectivement travaillé! Assurez-vous d'ajouter -static pour les options du linker. Le seul problème est que je ne peux en trouver un avec GCC 4.7.0, ce qui implique de renoncer à certains autres C++11 caractéristiques jusqu'à ce qu'un autre plus récent est construit.
Double Possible de mingw-w64 threads: posix vs win32

OriginalL'auteur arjun | 2013-01-07

  1. 15

    Il m'est arrivé de regarder le même problème. GCC fonctionne très bien avec std::mutex sous Linux. Toutefois, sur Windows, les choses semblent être pire. Dans le <mutex> fichier d'en-tête fourni avec MinGW GCC 4.7.2 (je crois que vous êtes en utilisant un MinGW GCC version trop), j'ai trouvé que la classe mutex est défini en vertu de la suivante #if garde:

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

    Malheureusement, _GLIBCXX_HAS_GTHREADS n'est pas défini sur Windows. Le support d'exécution est tout simplement pas là.

    Vous pouvez également poser des questions directement sur le MinGW liste de diffusion, dans le cas où certains gourous de la GCC peut vous aider.

    EDIT: Le MinGW-w64 projets fournit le support d'exécution. Découvrez http://mingw-w64.sourceforge.net/

    OriginalL'auteur Yongwei Wu

  2. 12

    Cela a maintenant été inclus dans MingW (Version 2013072300). Pour l'inclure, vous devez sélectionner le pthreads dans le Gestionnaire d'Installation de MinGW.

    C++ mutex dans l'espace de noms std n'est pas le nom d'un type de

    Cela n'a pas à faire le truc sur au moins un système.
    Veuillez fournir les informations système, y compris vous MingW version de sorte qu'il peut aider d'autres personnes
    Désolé: Windows, mingw32-pthreads-w32 2.10-pré-20160821-1, ce qui semble être la plus récente, nous pouvons le mettre à jour; dit encore std::mutex does not name a type
    Merci @JohnPerry je vais voir si j'ai une mise à jour de ma réponse basée sur cette version.

    OriginalL'auteur geekonedge

  3. 5

    Mutex, au moins, n'est pas pris en charge dans le 'modèle de Thread: win32" de la Mingw-construit toolchains. Vous devez sélectionner l'une des toolchains avec "modèle de Thread: posix'. Après avoir essayé avec plusieurs versions et révisions (les deux architectures i686 et x86_64) j'ai seulement trouvé un appui dans x86_64-4.9.2-posix-seh-rt_v3-rev1 étant le modèle de thread, de l'OMI, le facteur déterminant.

    OriginalL'auteur Walter Waldo

  4. 2

    Je ne sais pas si cela fonctionne pour tout le monde, mais d'une autre manière, vous avez juste à mettre à jour votre ndk. Je suis l'aide de ndk-r11c et il fonctionne parfaitement.

    OriginalL'auteur Bastienm

  5. 1

    J'ai eu la même erreur avec gcc4.7.7.

    Après l'ajout de "-std=c++0x", il est fixe.

    OriginalL'auteur Doan Quang Viet

  6. 0

    Je suis confronté à cette erreur aujourd'hui, et il fixe par étapes suivantes:

    • Project > Build option...
    • La sélection par défaut du compilateur: GCC Compilateur
    • Sur l'onglet "paramètres du Compilateur /drapeaux du Compilateur", cocher l'option
      "G++ suivez le C++11 ISO langage C++ standard [std=c++11]"

    Bonne chance.

    OriginalL'auteur TungBui

  7. 0

    J'ai rencontré ce même problème lors de l'utilisation de MingW-W64 7.2.0. J'ai testé plusieurs Fenêtres différentes construit à partir de la mingw-64 page de téléchargement, et a constaté que MinGW-W64 avec GCC-8.1.0 prend en charge mutex et contient les pthread de la bibliothèque. Lors de l'installation, j'ai choisi l'une des options suivantes:

    • x86_64
    • posix
    • seh

    Mon multi-threaded code basé sur pthreads maintenant compile et s'exécute correctement sur Windows et Linux sans aucune modification.

    C++ mutex dans l'espace de noms std n'est pas le nom d'un type de

    Cette version est plus maigre que le 7.3.0 construire, j'ai été à l'aide car il n'a pas un environnement CygWin ou le gestionnaire de package. J'ai aussi copié mingw32-make.exe à make.exe donc mon Makefile n'a pas besoin d'être modifié. Le programme d'installation crée un "Run terminal" dans le Menu Démarrer de Windows.

    C++ mutex dans l'espace de noms std n'est pas le nom d'un type de

    OriginalL'auteur vallismortis

  8. 0

    Utiliser des threads POSIX, modèle pour MINGW:

    $ 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>

    Voir aussi: mingw-w64 threads: posix vs win32

    OriginalL'auteur Amir Saniyan

  9. -3

    De nombreuses classes de la norme bibliothèque de threads peut être remplacé avec le coup de pouce. Une très facile de contourner le problème est de changer la totalité du standard mutex fichier avec un couple de lignes.

    #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;
}

    Et n'oubliez pas de lien à l'encontre de stimuler la bibliothèque de threads.

    C'est peut-être trop, surtout si vous ne travaillez pas avec boost
    l'extension de la std espace de noms comme ce rendements UB. en.cppreference.com/w/cpp/language/extending_std

    OriginalL'auteur Kolyunya