是的，有许多更改将导致相同的代码导致C ++ 03和C ++ 11之间的行为不同。排序规则的差异导致一些有趣的变化，包括一些以前未定义的行为变得清晰。
1.初始化列表中同一变量的多个突变
一个非常有趣的极端情况是初始化器列表中同一变量的多个突变，例如：
int main()
{
int count = 0 ;
int arrInt[2] = { count++, count++ } ;
return 0 ;
}
在C ++ 03和C ++ 11中都对此进行了很好的定义，但是未指定C ++ 03 中的求值顺序，但在C ++ 11中，它们的显示顺序是按它们出现的顺序求值的。因此，如果我们clang在C ++ 03模式下进行编译，则会提供以下警告（实时查看）：
warning: multiple unsequenced modifications to 'count' [-Wunsequenced]
int arrInt[2] = { count++, count++ } ;
^ ~~
但在C ++ 11中未提供警告（请实时查看）。
2.新的排序规则使i = ++ i + 1；在C ++ 11中定义良好
C ++ 03之后采用的新排序规则意味着：
int i = 0 ;
i = ++ i + 1;
在C ++ 11中不再是未定义的行为，缺陷报告637中对此进行了说明。排序规则和示例不一致
3.新的排序规则也使++++ i; 在C ++ 11中定义良好
C ++ 03之后采用的新排序规则意味着：
int i = 0 ;
++++i ;
在C ++ 11中不再是未定义的行为。
4.稍微更明智的签名左移
C ++ 11的后续草案包括N3485我在下面链接的内容，修复了将1位移入或移出符号位的不确定行为。缺陷报告1457中也对此进行了说明。霍华德·海因南特（Howard Hinnant ）在C ++ 11中的左移（<<）是否为负整数未定义行为上对此线程的更改的重要性进行了评论。。
5. constexpr函数在C ++ 11中可以视为编译时常量表达式
C ++ 11引入了constexpr函数，这些函数：
constexpr说明符声明可以在编译时评估函数或变量的值。这样的变量和函数可以在仅允许编译时常数表达式的地方使用。
尽管C ++ 03不具有constexpr功能，但是我们不必显式使用constexpr关键字，因为标准库在C ++ 11中提供了许多函数constexpr。例如std :: numeric_limits :: min。这可能导致不同的行为，例如：
#include <limits>
int main()
{
int x[std::numeric_limits<unsigned int>::min()+2] ;
}
clang在C ++ 03中使用，这将导致x它是一个可变长度的数组，这是一个扩展，并将生成以下警告：
warning: variable length arrays are a C99 feature [-Wvla-extension]
int x[std::numeric_limits<unsigned int>::min()+2] ;
^
而在C ++ 11中，std::numeric_limits<unsigned int>::min()+2则是编译时常量表达式，不需要VLA扩展。
6.在C ++ 11中，为析构函数隐式生成noexcept异常规范
由于在C ++ 11中，用户定义的析构函数具有隐式noexcept(true)规范，如noexcept析构函数中所述，因此它意味着以下程序：
#include <iostream>
#include <stdexcept>
struct S
{
~S() { throw std::runtime_error(""); } // bad, but acceptable
};
int main()
{
try { S s; }
catch (...) {
std::cerr << "exception occurred";
}
std::cout << "success";
}
在C ++ 11中将调用，std::terminate但将在C ++ 03中成功运行。
7.在C ++ 03中，模板参数不能具有内部链接
为什么std :: sort不接受在函数中声明的Compare类，对此进行了很好的介绍。因此，以下代码在C ++ 03中不起作用：
#include <iostream>
#include <vector>
#include <algorithm>
class Comparators
{
public:
bool operator()(int first, int second)
{
return first < second;
}
};
int main()
{
class ComparatorsInner : public Comparators{};
std::vector<int> compares ;
compares.push_back(20) ;
compares.push_back(10) ;
compares.push_back(30) ;
ComparatorsInner comparatorInner;
std::sort(compares.begin(), compares.end(), comparatorInner);
std::vector<int>::iterator it;
for(it = compares.begin(); it != compares.end(); ++it)
{
std::cout << (*it) << std::endl;
}
}
但目前clang除非允许您使用-pedantic-errors标志（有点怪异）才能在C ++ 03模式下允许此代码带有警告，否则请实时查看。
8.关闭多个模板时>>不再格式不正确
使用>>接近多个模板不再是病态的，但可能会导致不同的结果代码在C ++ 03和C + 11。以下示例取自右尖括号和向后兼容性：
#include <iostream>
template<int I> struct X {
static int const c = 2;
};
template<> struct X<0> {
typedef int c;
};
template<typename T> struct Y {
static int const c = 3;
};
static int const c = 4;
int main() {
std::cout << (Y<X<1> >::c >::c>::c) << '\n';
std::cout << (Y<X< 1>>::c >::c>::c) << '\n';
}
在C ++ 03中的结果是：
0
3
在C ++ 11中：
0
0
9. C ++ 11更改了一些std :: vector构造函数
从此答案中稍作修改的代码表明，使用std :: vector中的以下构造函数：
std::vector<T> test(1);
在C ++ 03和C ++ 11中产生不同的结果：
#include <iostream>
#include <vector>
struct T
{
bool flag;
T() : flag(false) {}
T(const T&) : flag(true) {}
};
int main()
{
std::vector<T> test(1);
bool is_cpp11 = !test[0].flag;
std::cout << is_cpp11 << std::endl ;
}
10.缩小聚合初始值设定项中的转换
在C ++ 11中，聚合初始化程序中的缩小转换格式不正确，gcc尽管在C ++ 11中默认情况下会提供警告，但在C ++ 11和C ++ 03中似乎都允许这样做：
int x[] = { 2.0 };
这在C ++ 11标准草案的8.5.4 列表初始化第3段中有所介绍：
对象或类型T的引用的列表初始化定义如下：
并包含以下项目符号（重点是我的）：
否则，如果T是类类型，则考虑构造函数。列举了适用的构造函数，并通过重载决议（13.3、13.3.1.7）选择了最佳的构造函数。如果需要缩小转换（请参阅下文）以转换任何参数，则程序格式错误
这和许多实例均包含在草案C ++标准部分annex C.2 的C ++和ISO C ++ 2003。它还包括：
新型的字符串文字，特别是，与字符串文字相邻时，名为R，u8，u8R，u，uR，U，UR或LR的宏将不会扩展，但会被解释为字符串文字的一部分。例如
#define u8 "abc"
const char *s = u8"def"; // Previously "abcdef", now "def"
用户定义的文字字符串支持以前，＃1本应由两个单独的预处理标记组成，并且宏_x已扩展。在此国际标准中，＃1由单个预处理令牌组成，因此该宏不会扩展。
#define _x "there"
"hello"_x // #1
为整数/和使用整数除法的％2003代码的结果指定舍入，将结果朝0或朝负无穷大舍入，而此国际标准始终将结果舍入到0。
现在，size（）成员函数的复杂度保持不变。某些符合C ++ 2003的容器实现可能不符合本国际标准中指定的size（）要求。将容器（例如std :: list）调整为更严格的要求可能需要进行不兼容的更改。
更改std :: ios_base :: failure的基类[...] std :: ios_base :: failure不再直接从std :: exception派生，而是现在从std :: system_error派生，后者又从中派生std :: runtime_error。假定std :: ios_base :: failure直接源自std :: exception的有效C ++ 2003代码在本国际标准中的执行方式可能有所不同。
auto会导致这种情况