Clang> = 3.3 en mode c ++1y ne peut pas analyser <cstdio> entête

Question

J'ai un projet que correctement compile et s'exécute sous g++ 4.8.1 et clang >= 3.3 en c++11 mode. Cependant, lorsque je passe à l'expérimentation -std=c++1y mode, clang 3.3 (mais pas g++) étouffe sur l' <cstdio> - tête qui est indirectement inclus par voie de Boost.Test (donc je ne peut pas facilement changer moi-même)

// /usr/include/c++/4.8/cstdio
#include <stdio.h>

// Get rid of those macros defined in <stdio.h> in lieu of real functions.
// ...
#undef gets
// ...    

namespace std
{
// ...
using ::gets; // <-- error with clang++ -std=c++1y
// ...
}

avec le message d'erreur suivant:

/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/cstdio:119:11: erreur: aucun membre nommé 'obtient' dans l'espace de noms global

Sur ce tutoriel sur la façon de mettre en place un cadre moderne environnement C++, une semblable recherche de problème avec max_align_t est rencontré. La recommandation qui y est d'utiliser un script sed pour entourer les symboles inconnus avec #ifdef __clang__ des macros, mais qui semble fragile approche.

Programme d'installation: plaine 64 bits de Linux Mint 15 avec

g++ (Ubuntu 4.8.1-2ubuntu1~13.04) 4.8.1

Ubuntu clang version 3.3-3~raring1 (branches/release_33) (sur la base LLVM 3.3)

Questions:

• ce qui est à l'origine de ce erorr? Il n'y a pas d' __clang__ macro n'importe où près le code en question, et clang en c++11 mode n'a pas de mal à tous.
• Est-ce un problème de langage (C++14 dire autre chose que du C++11 à propos de l'importation de C compatible avec les symboles du mondial dans l' std d'espace de noms)?
• Dois-je changer quelque chose avec mes chemins à inclure? (J'utilise CMake pour sélectionner automatiquement l'en-tête de chemins, et de basculer entre les modes à l'intérieur de CMakeLists.txt)
• Ne clang, un commutateur à résoudre ce problème?

Answer 1

Cette note dans la page de manuel gets semble pertinente:

ISO C11 supprime la spécification de gets () du langage C et, depuis la version 2.16, les fichiers d'en-tête glibc n'exposent pas la déclaration de fonction si la macro de test de fonctionnalité _ISOC11_SOURCE est définie.

Devrait probablement être

 #if !_ISOC11_SOURCE
using ::gets;
#endif