假设我有一个不使用任何C ++ 11的跨平台（Win＆amp; Mac）生产代码库。
假设mac上的编译器选项已更改为使用C ++ 11语言方言，但没有C ++ 11标准库。
我曾尝试使用谷歌搜索来了解可能的影响，但我的空洞。
我的问题是：
答案 0 :(得分：5)
我不使用XCode，但我想如果他们为clang运送一个（可能是不完整的但是到达那里）C ++ 11模式，那么他们也会运送一个（可能不完整但是到达那里）C + +11标准库。并一起测试它们。所以你的情况不应该出现，但假设它仍然存在：
形式上它没有任何意义，因为标准不承认混合和匹配“语言”和“库”的任何方式。这取决于你的编译器它认为它意味着什么。可能意味着新的“语言特征”如rvalue引用，lambdas等变得可用，但命名空间std中的新类和函数不可用。
主要风险可能是您不再按照公认的标准进行编程，而是编写了编译器发明的可能记录不足的事情。如果编译器说在C ++ 11模式下它需要一个C ++ 11标准库，并且你提供了一个C ++ 03标准库，那么你甚至不需要编译器文档 - 任何可能发生了，你打破了它，你的错。
除了这种有趣组合的风险之外，采用C ++ 03代码库并使用任何 C ++ 11编译器编译它的风险很小。 C ++ 03中有一些代码构造，它们编译为C ++ 11但具有微妙（或严重）不同的含义。
例如，它几乎可以在C ++ 03中编写一个在C ++ 11中使用时会中断的类，因为C ++ 11将生成一个不能正常运行的移动构造函数。有时你必须替换编译器生成的复制构造函数，它不能做正确的事情（Rule of Three），而C ++ 11确保在那些“正常”情况下移动构造函数被抑制，有一些奇怪的边缘案例。不幸的是，我现在还记不住了。
C ++ 11标准列出了C ++ 11和C ++ 03之间的一些不兼容性。你希望所有人，但你知道它是怎么回事。该清单在附录C中。它以：
开头有效的C ++ 2003代码可能无法编译或产生不同的结果 在本国际标准中。具体来说，名为
R，u8，u8R的宏， 邻近字符串时，u，uR，U，UR或LR不会展开 文字，但将被解释为字符串文字的一部分。
并没有从那里得到更多的阅读。但它基本上是一个列表，如果它们出现在你的C ++ 03代码库中，需要改变以获得等效的C ++ 11。
答案 1 :(得分：1)
没有真正的'风险'，但C ++ 11的很多价值来自图书馆。
将语言更改为C ++ 11意味着支持C ++ 11语言功能。如果你看一下标准，你会发现它分为语言（第1-16条）和图书馆（第17-30条）特征。语言功能包括语法，表达和语句的含义，重载决策等。库功能涵盖标准标题的内容。因此，如果你需要一个特定的头来在C ++ 11中做某事，那么你可能需要一个C ++ 11标准库。
Xcode支持随gcc 4.2一起提供的libstdc ++版本，并且是为C ++ 03构建的。当clang设置为C ++ 11模式时，这很好用。它还支持libc ++，它旨在提供许多C ++ 11功能，即使使用C ++ 03编译器也是如此。因此混合和匹配在大多数情况下应该可以正常工作。但是，通过使用为彼此设计的语言和库，您将获得更多价值。
答案 2 :(得分：0)
不要忘记许多C ++ 11语言功能都受到库功能的支持 - 例如，如果没有std::move和std::forward，您将无法使用rvalue引用，初始化列表也将是垃圾。
答案 3 :(得分：0)
GCC和clang编译c ++略有不同。这可能对你的情况没有任何影响，但在别人的情况下，你可以切换回GNU风格的编译。因此“语言方言”。
只要你将语言和stdlib设置为GNU版本，就不应该有所作为。但是使用GNU方言中的Apple LLVM编译器（clang）进行编译可能不会产生与Windows相同的结果（假设您在两者上都使用GCC）。我会说除非你在两个平台上使用匹配的库，编译器和设置，否则你总是处于危险之中，特别是当第三方库发挥作用时，你将libstdc ++与libc ++交换为C ++ 11支持。
如果你在Windows上使用VC ++，它的C ++ 11支持相当缺乏，所以当你的XCode代码拒绝在VC ++中构建时不要感到惊讶。