はい、同じコードが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でも取り上げられています。ハワード・ヒナントは、C ++ 11での左シフト（<<）は負の整数の未定義の動作であるというスレッドのこの変更の重要性についてコメントしています。。
5. constexpr関数は、C ++ 11ではコンパイル時の定数式として扱うことができます
C ++ 11はconstexpr関数を導入しました：
constexpr指定子は、コンパイル時に関数または変数の値を評価できることを宣言します。このような変数と関数は、コンパイル時の定数式のみが許可されている場所で使用できます。
C ++ 03にはconstexpr機能がありませんが、標準ライブラリはC ++ 11でconstexprとして多くの関数を提供しているため、明示的にconstexprキーワードを使用する必要はありません。たとえば、std :: numeric_limits :: minです。たとえば、次のような異なる動作が発生する可能性があります。
#include <limits>
int main()
{
int x[std::numeric_limits<unsigned int>::min()+2] ;
}
clangC ++ 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では、デストラクターの例外仕様は暗黙的に生成されます
C ++ 11では、ユーザー定義のデストラクタにはnoexceptデストラクタでnoexcept(true)説明されている暗黙の指定があるため、次のプログラムを意味します。
#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、あなたが使用しない限り、このコードは、警告とC ++ 03モードで可能に-pedantic-errors一種不快のあるフラグを、それが生きてご覧ください。
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 ++ 03の両方でこれを許可しているように見えますが、C ++ 11ではデフォルトで警告が表示されます。
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は2つの別々の前処理トークンで構成され、マクロ_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このような状況になる可能性があると確信しています