在GCC / MinGW文件夹树中，文件夹中有一些头文件名重复：ssp，ext，tr1; parallel，ext，bits和experiemental ......
应该明确＆＃34;包括＆＃34;在生产代码中避免使用这些文件夹的指令 - 作为最佳实践 ？
或者，是否有在线文档，关于这些文件夹应在#include语句中明确使用的合法方案？
注意： 1. SSP :( Stack Smashing Protector） 2. tr1：技术报告1，（Stack Link）似乎已被弃用。
C ++ 11和C ++ 14：
Eclipse CDT，使用Clang ToolChain，Google Test API和MinGW（5.1）。
在发布此帖子时，Clang's LibC++尚未针对Windows构建，因此使用MinGW：Posix，SEH，X86_64，捆绑。
<stdio.h>文件夹：<algorithm>文件夹：答案 0 :(得分：2)
（从评论中移动/扩展）
我总是看到从这些位置明确包含的内容，例如<bits/c++config.h>，<ext/bitmap_allocator.h>，<tr1/cmath>等，从不将其中一个目录直接添加到包含搜索路径。请注意，据我所知，bits目录应该大部分保留，因为它包含特定于实现版本的东西（不一定是稳定的API）。我找不到这方面的明确文档，但是库的一般结构（在根中包含标准公共头文件，包括他们的bits对应文件）似乎是这样建议的。
这些是否应该作为最佳做法避免？或者，它们应该被利用的场景是什么？
排除bits，其他所有内容都可以使用，只要您愿意接受您依赖于libstdc++而不是单独的标准C ++，如{{3 }}：
＆＃34;较少的非标准＆＃34;东西就是你在tr1找到的东西;它来自http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html，它不是真正的＆＃34;标准，但建议将包含在即将到来的C ++ 11标准中;在2011之前你可以使用它并期望与其他编译器有一定程度的互操作性，今天你可以放心地忽略它并且只使用C ++ 11（实际上是标准化的，并且在一些细节上有很大不同）。
所有ext都是libstdc ++扩展，有些是来自SGI STL，有些是更新的开发;它们中的一些将被包含在一些标准C ++提案中并非不可能，但在这种情况下，它们可能会移动到其他地方。
parallel目录包含一些经典STL算法（C++ TR1）的并行实现;再次，IIRC有一个标准化它们的提议，但如上所述，我希望它们能够移动到其他地方，以防它们标准化，因为很少标准化使提案完好无损，而且他们需要一种方法让旧程序运行良好使用旧的标题/语义。
experimental包含新实验技术规范的内容（概念类似于TR1），应该毕业于真实的＆＃34;新标准发布时的标准库;在我的gcc 4.9.2安装中，我只能在那里找到string_view和optional，但details here;就个人而言，与tr1一样，在生产代码中使用这些标题之前，我会等待新的标准，因为，就像它们一样，它们仍然是一个移动目标，并且代码质量不在与图书馆的其他部分相提并论（正如名称所说，它仍然是实验性的东西）。
ssp文件夹包含Stack Smashing Protector。来自OSDev，（some other stuff should come）：
如果通过编译器选项请求，或者如果编译器供应商默认启用它，则GCC等编译器会启用此功能。如果您的操作系统具有安全意识且您提供支持，则默认启用它是值得考虑的。