C++ GCC/MinGW 路径：ssp、ext、tr1；并行、分机、位、实验
C++ GCC/MinGW Paths: ssp, ext, tr1; parallel, ext, bits, experimental
问题：
在GCC/MinGW文件夹树中，有一些头文件名重复，在文件夹中：ssp、ext、tr1；并行、分机、位和实验...
作为最佳实践，是否应该在生产代码中避免对这些文件夹使用显式 "include" 指令？？
或者，是否有关于这些文件夹应该在#include 语句中明确使用的合法场景的在线文档？
备注：
1. SSP：（Stack Smashing Protector）
2. tr1：技术报告 1，(Stack Link)，似乎已弃用。
工具链：
C++ 11 和 C++ 14：
Eclipse CDT, using the Clang ToolChain, with Google Test API, and MinGW (5.1).
此时 post，Clang's LibC++ 还没有为 Windows 构建，所以使用 MinGW：Posix，SEH，X86_64 , 捆绑。
<stdio.h> 文件夹：
- include/stdio.h
- include/c++/tr1/stdio.h
- lib/gcc/x86_0w64-mingw32/5.1.0/include/ssp/stdio.h
<algorithm> 文件夹：
- include/c++/算法
- include/c++/experimental/algorithm
- include/c++/ext/algorithm
- include/c++/parallel/algorithm
（moving/expanding 来自评论）
我一直看到从这些位置明确包含的内容，例如<bits/c++config.h>、<ext/bitmap_allocator.h>、<tr1/cmath> 等，切勿将其中一个目录直接添加到包含搜索路径。请注意，就我一直以来的理解而言，bits 目录应该保持独立，因为它包含 implementation-version 特定的内容（不一定是稳定的 API-wise）。我找不到这方面的明确文档，但是库的一般结构（根目录中的标准 public headers 包括它们的 bits 对应项）似乎表明如此。
Should these be avoided as a best practice? Or, what are the scenarios they should be utilized?
除了 bits，其他的都可以使用，只要你愿意接受你依赖于 libstdc++ 而不是单独的标准 C++，如 http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html:
"less nonstandard" 内容就是您在 tr1 中找到的内容；它来自 C++ TR1，它不是 "real" 标准，而是对要包含在 then-upcoming C++11 标准中的内容的建议；在 2011 年之前你可以使用它并期望与其他编译器有一定程度的互操作性，今天你可以安全地忽略它并只使用 C++11（它实际上是标准化的并且在一些细节上有很大不同）。
所有 ext 都是 libstdc++ 扩展，一些是来自 SGI STL 的东西，一些是更新的开发；它们中的一些将包含在某些标准 C++ 提案中并非不可能，但在那种情况下它们可能会移到其他地方。
parallel目录包含一些经典STL算法的并行实现（details here）；再次，IIRC 有一个标准化它们的提案，但如上所述，我希望它们在标准化的情况下移动到其他地方，因为标准化很少使提案完好无损，并且他们需要一种方法让旧程序 运行 和旧的 headers/semantics.
没关系
experimental 包含新的实验性技术规范（概念类似于 TR1）的内容，当新标准发布时应该升级到 "real" 标准库；目前在我的 gcc 4.9.2 安装中我只能在其中找到 string_view 和 optional，但是 some other stuff should come；就我个人而言，与 tr1 一样，我会等待潮流在新标准中稳定下来，然后再在生产代码中使用这些 headers，因为，就目前而言，它们仍然是一个移动的目标，并且代码质量与图书馆的其他部分不相上下（正如名字所说，它仍然是实验性的东西）。
ssp 文件夹包含 Stack Smashing Protector 内容。来自 OSDev，(Link):
Compilers such as GCC enables this feature if requested through compiler options, or if the compiler supplier enabled it by default. It is worth considering enabling it by default if your operating system is security conscious and you provide support.
问题：
在GCC/MinGW文件夹树中，有一些头文件名重复，在文件夹中：ssp、ext、tr1；并行、分机、位和实验...
作为最佳实践，是否应该在生产代码中避免对这些文件夹使用显式 "include" 指令？？
或者，是否有关于这些文件夹应该在#include 语句中明确使用的合法场景的在线文档？
备注： 1. SSP：（Stack Smashing Protector） 2. tr1：技术报告 1，(Stack Link)，似乎已弃用。
工具链：
C++ 11 和 C++ 14：
Eclipse CDT, using the Clang ToolChain, with Google Test API, and MinGW (5.1).
此时 post，Clang's LibC++ 还没有为 Windows 构建，所以使用 MinGW：Posix，SEH，X86_64 , 捆绑。
<stdio.h> 文件夹：
- include/stdio.h
- include/c++/tr1/stdio.h
- lib/gcc/x86_0w64-mingw32/5.1.0/include/ssp/stdio.h
<algorithm> 文件夹：
- include/c++/算法
- include/c++/experimental/algorithm
- include/c++/ext/algorithm
- include/c++/parallel/algorithm
（moving/expanding 来自评论）
我一直看到从这些位置明确包含的内容，例如<bits/c++config.h>、<ext/bitmap_allocator.h>、<tr1/cmath> 等，切勿将其中一个目录直接添加到包含搜索路径。请注意，就我一直以来的理解而言，bits 目录应该保持独立，因为它包含 implementation-version 特定的内容（不一定是稳定的 API-wise）。我找不到这方面的明确文档，但是库的一般结构（根目录中的标准 public headers 包括它们的 bits 对应项）似乎表明如此。
Should these be avoided as a best practice? Or, what are the scenarios they should be utilized?
除了 bits，其他的都可以使用，只要你愿意接受你依赖于 libstdc++ 而不是单独的标准 C++，如 http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_headers.html:
"less nonstandard" 内容就是您在 tr1 中找到的内容；它来自 C++ TR1，它不是 "real" 标准，而是对要包含在 then-upcoming C++11 标准中的内容的建议；在 2011 年之前你可以使用它并期望与其他编译器有一定程度的互操作性，今天你可以安全地忽略它并只使用 C++11（它实际上是标准化的并且在一些细节上有很大不同）。
所有 ext 都是 libstdc++ 扩展，一些是来自 SGI STL 的东西，一些是更新的开发；它们中的一些将包含在某些标准 C++ 提案中并非不可能，但在那种情况下它们可能会移到其他地方。
parallel目录包含一些经典STL算法的并行实现（details here）；再次，IIRC 有一个标准化它们的提案，但如上所述，我希望它们在标准化的情况下移动到其他地方，因为标准化很少使提案完好无损，并且他们需要一种方法让旧程序 运行 和旧的 headers/semantics.
experimental 包含新的实验性技术规范（概念类似于 TR1）的内容，当新标准发布时应该升级到 "real" 标准库；目前在我的 gcc 4.9.2 安装中我只能在其中找到 string_view 和 optional，但是 some other stuff should come；就我个人而言，与 tr1 一样，我会等待潮流在新标准中稳定下来，然后再在生产代码中使用这些 headers，因为，就目前而言，它们仍然是一个移动的目标，并且代码质量与图书馆的其他部分不相上下（正如名字所说，它仍然是实验性的东西）。
ssp 文件夹包含 Stack Smashing Protector 内容。来自 OSDev，(Link):
Compilers such as GCC enables this feature if requested through compiler options, or if the compiler supplier enabled it by default. It is worth considering enabling it by default if your operating system is security conscious and you provide support.