C++11 为什么在使用gcc-std=c++；11?

使用

gcc-std=c++11

，程序可能无法在Cygwin中编译。头文件编译正常（除非它们像boost/asio.hpp一样试图使用缺少的定义）。现在，由于Cygwin的

#ifdef

宏绕过了c++11环境中的一些函数定义，程序可能不会。当相同的源文件在FedoraLinux上以类似方式编译时，不会发生这种情况

此示例程序无法使用gcc-std=c++11选项编译：

#include <boost/asio.hpp>
int main() { return 0; }

#包括
int main（）{return 0；}

我首先发现上面的程序没有编译，然后在使用更新的标准重新编译现有代码时发现了更多类似的问题

回复中列出了我发现被破坏的include部分

---

[编辑以更正打字错误。]

在更新Cygwin include库之前，您可以使用以下解决方法：

在源代码中，包括

#define _GNU_SOURCE

在任何其他包括之前。在FedoraLinux中不需要此解决方法，仅在Cygwin环境中，然后仅使用-std=compiler选项

这修复了：

#include <boost/asio.hpp> // (Because it uses sigfillset from sys/signal.h)
#include <sys/signal.h>   // sigfillset and others declared nearby
#include <sys/types.h>    // u_int and other __MISC_VISIBLE typedefs
#include <stdio.h>        // at least fileno
#include <string.h>       // at least strdup

---

在文件的开头附近。虽然这对临时的库用户有效，但这不是Cygwin开发人员将使用的方法。

使用Cygwin使用

-std=gnu++11

，而不是

-std=c++11

---

对于Cygwin，我发现

-std=c++11

似乎排除了GNU扩展，并导致Boost和POSIX头出现各种问题。

为什么不改用

-std=GNU++11

？谢谢@MarkGlisse。我使用了在文档中找到的

c++11

选项。直到你指出了新标准，我才意识到还有另外一种指定新标准的方法。（你的方法更好。升级或重新安装boost时，问题不会再次出现。）默认是GNU源代码。为什么要使用gcc-std=c++11？或者是C或C++，我不理解用C++标准调用C OMPLE，结果我实际上使用了<代码> C++ +STD= C++ 11 。但是，使用GCC、C++、G++都会发生同样的故障。如果你谷歌“GNU C++编译器”，GCC就是出现的。它是一个C++编译器。/Ur/bin /gCC和/ur/bin /g++是两种不同语言的两种不同编译器。它们是相关的，就像语言是相关的一样，但并不完全相同。我不清楚您是否在没有

-std=c++11

#ifndef _GNU_SOURCE // LOCAL WORK-AROUND
#define _GNU_SOURCE
#endif