积极使用的C++环境缺乏对标准库的支持(如果不是全部的话，也是大多数）

C++标准库支持在不同的编译器供应商之间，甚至在同一编译器的不同版本之间都可能有所不同。在嵌入式系统和各种控制台上尤其如此。

我所说的"变化"是指可能存在错误、以不同方式实现的功能，甚至缺少功能。例如，Android有一个非常简单的C++标准库实现。

有许多奇怪而奇妙的C++编译器；不仅仅是GCC和Visual Studio。例如，任天堂使用Green Hills编译器。

因此，由于编译器种类繁多，支持大量编译器的最佳方法是只使用C标准库提供的功能。许多可移植库甚至避免使用更现代的C++功能。

我能想到的只有独立的环境（操作系统和单进程嵌入式程序）。当然，一些开发人员积极避免使用STL，但这更多的是一个设计决定，而不是环境中缺乏支持。我认为，在这些受约束的环境中，最大的障碍是异常支持（许多STL函数都会抛出异常支持）。为了获得对这些的支持，必须移植一个C++ABI和展开库（进行堆栈展开并转到catch语句）。没有什么能阻止人们实现这些必需的位，但更多的依赖性显然会导致膨胀，只是为了对链表之类的东西提供基本支持。要移植ABI，请参阅OSDEV wiki条目。

对于较新的C++标准（C++11以后），还有其他依赖项。我可以想象std:：thread需要一个线程实现，比如pthreads。std:：chrono可能需要在它和C标准库时间之间实现一些中间层。可能还有更多STL功能需要操作系统支持。

STL的模板部分也相当重要。模板通常会大大增加最终二进制文件的大小。例如，在std:：列表的情况下，std::list<MyClass1>和std::list<MyClass2>将导致两个不同容器的专业化。代码看起来非常相似，但会被复制以专门处理它们的元素类型。链表的其他实现通常使用一个指向链接节点的void指针，然后在需要时将其强制转换为适当的类。通过这种方式，int、char*、MyClass1等有一个实例化的列表类。二进制大小的增加在嵌入式环境中通常是不可接受的，但必须注意的是，当LibA实现LibA:：LinkedList和LibB LibB:：LinkedList时，这也会成为一个问题。

如今，实现的质量已不再是一个问题。GCC针对许多体系结构也很有帮助，这样就可以使用新的编译器标准（如上所述，您仍然需要移植STL的一些功能）。我使用过的最古老的GCC是GCC v4.3或类似的嵌入式PowerPC设备。它于2010年发布，并得到了STL的全面支持。

总之，对具有非常集中的功能集的库的需求仍然会有所帮助，但在我看来，如果它们提供了包装操作系统相关行为的功能，那么它们会减少项目目标平台的数量。对于原始数据结构和算法支持，您不会出错。最后，您必须针对平台的某个子集。在C++11中，我相信您的目标是99%的台式机/服务器操作系统和99%的嵌入式Linux设备。正如另一个答案中强调的那样，Android一直是一个问题，但本页似乎强调了获得真正现代环境所需的所有功能。

简单的答案是，当您选择不包含STL包时。

对于大多数IDE，如果您的项目没有调用STL的#include <package_name>项，则在编译时不包括STL。

尽管在某些情况下，您必须通过IDE/编译器专门排除STL

避免STL的一个重要原因是减少最终编译的文件大小。