C++98とC++03が混在していたのでC++98に基本的に統一。C++03はDR程度なので言語バージョン専用ページはいまのところ作らない

lang/cpp11/alignas.md

@@ -102,7 +102,7 @@ alignas(8) alignas(16) int i8_16: 16
 * ハードウェアの制約を満たす
 * 同じアドレスに異なるデータを格納する
 
-C++03で変数のアライメントを行うにはコンパイラの拡張機能を利用するしかなく、コンパイラごとに異なる記述を行う必要があったが、C++11ではどのコンパイラでも同じ記述でアライメントができる。
+C++98で変数のアライメントを行うにはコンパイラの拡張機能を利用するしかなく、コンパイラごとに異なる記述を行う必要があったが、C++11ではどのコンパイラでも同じ記述でアライメントができる。
 
 
 ## 検討されたほかの選択肢

lang/cpp11/alignof.md

@@ -71,7 +71,7 @@ char *:            4
 
 
 ## この機能が必要になった背景・経緯
-C++03で型のアライメントサイズを得るにはコンパイラの拡張機能を利用するしかなく、コンパイラごとに異なる記述を行う必要があったが、C++11ではどのコンパイラでも同じ記述でアライメントサイズが取得できる。
+C++98で型のアライメントサイズを得るにはコンパイラの拡張機能を利用するしかなく、コンパイラごとに異なる記述を行う必要があったが、C++11ではどのコンパイラでも同じ記述でアライメントサイズが取得できる。
 
 
 ## 検討されたほかの選択肢

lang/cpp11/auto.md

@@ -26,7 +26,7 @@ auto f = []{};                      // f は 引数を取らずに値を返さ
 * std::make_shared[link ../../reference/memory/make_shared.md]
 
 型推論のための `auto` は、基本的には糖衣構文であり具体的な型で書き替えることが可能であるが、上記のクロージャ型のように書き換えが不可能なケースも存在する。  
-この機能の追加に伴って、C++03 までの `auto` に存在した、自動変数である事を意味する記憶クラス指定子としての使用はできなくなった。
+この機能の追加に伴って、C++98 までの `auto` に存在した、自動変数である事を意味する記憶クラス指定子としての使用はできなくなった。
 
 なお、`auto` は[戻り値の型を後置する関数宣言構文](trailing_return_types.md)でも使用されるが、その場合の `auto` には型推論の意味は無い。  
 さらに、C++14 では `auto` キーワードを使用する機能として、[ユーザ定義変換関数の型推論](../cpp14/return_type_deduction_for_normal_functions.md)、[通常関数の戻り値型推論](../cpp14/return_type_deduction_for_normal_functions.md)、[後置戻り値型をプレースホルダーにすることを許可](../cpp14/placeholder_type_in_trailing_return_type.md)、[ジェネリックラムダ](../cpp14/generic_lambdas.md)、および、[`decltype(auto)`](../cpp14/decltype_auto.md) が追加されている。  

lang/cpp11/decltype.md

@@ -229,7 +229,7 @@ template <class Func, class T>
 ??? trace(Func f, T t) { std::cout << "Calling f"; return f(t); }
 ```
 
-C++03 まででは、このような関数テンプレートの戻り値型をあらゆるケースで正確に表現することは不可能だった。
+C++98 まででは、このような関数テンプレートの戻り値型をあらゆるケースで正確に表現することは不可能だった。
 
 C++11 では、本機能と[戻り値の型を後置する関数宣言構文](trailing_return_types.md)を使用することによって、以下のように書くことができるようになった。
 

lang/cpp11/dependent_name_specifier_outside_of_templates.md

@@ -14,7 +14,7 @@
 
 テンプレート内で、推論できないテンプレートパラメータを持つメンバ関数を呼び出す場合には、メンバ関数名の前に`template`キーワードを付ける必要がある。
 
-C++03まで、テンプレート外で`typename`と`template`を付けるとコンパイルエラーになっていたが、C++11では、テンプレート外で`typename`と`template`を付けることが許可された。
+C++98まで、テンプレート外で`typename`と`template`を付けるとコンパイルエラーになっていたが、C++11では、テンプレート外で`typename`と`template`を付けることが許可された。
 
 これは、テンプレート内とテンプレート外で、共通のコードを利用できるようにするためである。
 

lang/cpp11/extend_friend_targets.md

@@ -10,7 +10,7 @@
 <!-- last lang caution -->
 
 ## 概要
-C++03までの`friend`宣言は、直接のクラス型のみを指定できた。
+C++98までの`friend`宣言は、直接のクラス型のみを指定できた。
 
 C++11では`friend`宣言が拡張され、テンプレートパラメータ、および型の別名もまた`friend`宣言できるようになった。
 

lang/cpp11/noexcept.md

@@ -72,7 +72,7 @@ struct X {
 * noexcept[color ff0000]
 
 - `noexcept`もしくは`noexcept(trueに評価される整数定数式)`が指定された関数が例外を送出した場合、[`std::terminate()`](/reference/exception/terminate.md)関数を呼び出してプログラムを異常終了させる。その際、[`std::terminate()`](/reference/exception/terminate.md)関数が呼び出される前に、スタックの巻き戻しは起こらない可能性がある。
-- 従来の`throw`キーワードによる例外仕様(C++03ではexception specification、C++11ではdynamic exception specificationと呼ばれる仕様)は、C++11以降で非推奨である。
+- 従来の`throw`キーワードによる例外仕様(C++98ではexception specification、C++11ではdynamic exception specificationと呼ばれる仕様)は、C++11以降で非推奨である。
 - `noexcept`の指定可能な位置は、[参照修飾](/lang/cpp11/ref_qualifier_for_this.md)の後、[戻り値の型を後置する関数宣言構文](/lang/cpp11/trailing_return_types.md)の前である。
 
 ### 式が例外を送出する可能性があるか判定するnoexcept演算子

lang/cpp11/nullptr.md

@@ -16,7 +16,7 @@
 int* p = nullptr;
 ```
 
-C++03まで、ヌルポインタを表すために`0`数値リテラルや[`NULL`](/reference/cstddef/null.md)マクロを使用していた。C++11からは、`nullptr`キーワードでヌルポインタ値を表すことを推奨する。
+C++98まで、ヌルポインタを表すために`0`数値リテラルや[`NULL`](/reference/cstddef/null.md)マクロを使用していた。C++11からは、`nullptr`キーワードでヌルポインタ値を表すことを推奨する。
 
 特定の型へのポインタではなく、`nullptr`のみを受け取りたい場合は、[`std::nullptr_t`][nullptr_t]型を使用する。
 

lang/cpp11/override_final.md

@@ -244,9 +244,9 @@ class D explicit : public B {
 - N2365では`[[check_names]]`、`[[new]]`、`[[hiding]]`属性（attribute）の追加と、`virtual`キーワードの意味の変更が提案された。
     - N2236にて属性が文法として提案されたため、それを使ったようだ。
     - `[[check_names]]`は明示的にオーバーライドのチェックを行う宣言である。
-    - `[[check_names]]`を指定しなければ、C++03までと同じ動作をする。
+    - `[[check_names]]`を指定しなければ、C++98までと同じ動作をする。
         - N2108では`[[check_names]]`の考え方がなかったため、過去との互換性が失われていた。
-        - オーバーライドのチェックの有無を選べるようにすることで、C++03で正しかったコードを破壊しないように配慮された。
+        - オーバーライドのチェックの有無を選べるようにすることで、C++98で正しかったコードを破壊しないように配慮された。
     - `[[new]]`は新たな仮想メンバ関数を宣言し、オーバーライドしていれば文法違反となる。
         - N2108の`new virtual`キーワードとほぼ同じアイデアである。
     - `[[hiding]]`は基底クラスの仮想メンバ関数をオーバーライドせず、同名の別関数で隠す（hiding）ことを宣言する。隠せていなければ文法違反となる。

lang/cpp11/range_based_for.md

@@ -14,7 +14,7 @@
 
 範囲for文が便利な例として、コンテナの各要素を処理するループを挙げる。
 
-C++03のfor文では以下のように書ける：
+C++98のfor文では以下のように書ける：
 
 ```cpp
 std::vector<int> v;
@@ -68,7 +68,7 @@ for-range-initializerにはfor文が処理すべき範囲を表す値を書く
 
 従って標準コンテナのみならず、ユーザ定義のクラスに対しても範囲for文を適用可能である。
 
-C++03のfor文と異なりセミコロンではなくコロンで区切ることに注意する。
+C++98のfor文と異なりセミコロンではなくコロンで区切ることに注意する。
 
 ### for文への展開
 

lang/cpp11/recursive_template_limit.md

@@ -10,7 +10,7 @@
 <!-- last lang caution -->
 
 ## 概要
-C++03まで、テンプレートの再帰回数は、「17回以上であることを実装に推奨する」というものであった。
+C++98まで、テンプレートの再帰回数は、「17回以上であることを実装に推奨する」というものであった。
 
 C++11からはこれが、1024回に緩和された。
 

lang/cpp11/reference_collapsing.md

@@ -10,7 +10,7 @@
 <!-- last lang caution -->
 
 ## 概要
-C++03までは、`T&`型に左辺値参照を足すと、「参照への参照 (reference to reference)」となってしまいコンパイルエラーとなっていた。
+C++98までは、`T&`型に左辺値参照を足すと、「参照への参照 (reference to reference)」となってしまいコンパイルエラーとなっていた。
 
 C++11では、型の別名定義、テンプレートパラメータ、および`decltype`の文脈において、`T&`型に左辺値参照を足しても`T&`型となることが規定された。これを「reference collapsing (参照を折りたたむ)」という。
 
@@ -22,7 +22,7 @@ int main()
 {
   typedef int& ir;
 
-  // C++03ではint& &となりコンパイルエラー
+  // C++98ではint& &となりコンパイルエラー
   // C++11ではint&となりOK
   typedef ir& irr;
 }
@@ -37,7 +37,7 @@ struct add_lvalue_reference {
   typedef T& type;
 };
 
-// C++03では、参照への参照にならないように、この部分特殊化が必要
+// C++98では、参照への参照にならないように、この部分特殊化が必要
 // C++11ではこの部分特殊化は必要ない (あっても問題はない)
 template <class T>
 struct add_lvalue_reference<T&> {

lang/cpp11/result_of_integer_division_and_modulo.md

@@ -10,13 +10,13 @@
 <!-- last lang caution -->
 
 ## 概要
-整数`a`, `b`に対する除算`a/b`の結果(商)と剰余算`a%b`の結果(余り)について`(a/b)*b + a%b = a`という等式が成り立つことが規定されているが、C++03まで、少なくとも一方が負の数である場合の余りの符号は実装定義だった。このため先述の等式により商も実装定義となっていた。C++11ではC99に合わせて「商の小数部がゼロ方向に切り捨てられた結果となること」が規定された。
+整数`a`, `b`に対する除算`a/b`の結果(商)と剰余算`a%b`の結果(余り)について`(a/b)*b + a%b = a`という等式が成り立つことが規定されているが、C++98まで、少なくとも一方が負の数である場合の余りの符号は実装定義だった。このため先述の等式により商も実装定義となっていた。C++11ではC99に合わせて「商の小数部がゼロ方向に切り捨てられた結果となること」が規定された。
 
 これにより、整数に対する除算と剰余算の結果が移植性のある値となるようになった。
 
 
 ## 仕様
-C++03では、余りの符号が以下のように規定されていた：
+C++98では、余りの符号が以下のように規定されていた：
 
 「両方の項が非負である場合、余りは非負となる。片方もしくは両方の項が負数である場合、余りの符号は実装定義となる。注釈：現在作業中のISO Cのリビジョン(C99のこと)とISO/IEC 1539:1991で標準化されているFortranの規格ではいずれも、整数に対する除算の商は必ずゼロ方向に丸められる。」
 
@@ -31,9 +31,9 @@ C++11では、C99との互換性のために、上記規定を置き換えて、
 
 int main()
 {
-  assert(-7 / +2 == -3 && -7 % +2 == -1); // C++03 までは商 -4 余り +1 となる実装も規格適合
-  assert(+7 / -2 == -3 && +7 % -2 == +1); // C++03 までは商 -4 余り -1 となる実装も規格適合
-  assert(-7 / -2 == +3 && -7 % -2 == -1); // C++03 までは商 +4 余り +1 となる実装も規格適合
+  assert(-7 / +2 == -3 && -7 % +2 == -1); // C++98 までは商 -4 余り +1 となる実装も規格適合
+  assert(+7 / -2 == -3 && +7 % -2 == +1); // C++98 までは商 -4 余り -1 となる実装も規格適合
+  assert(-7 / -2 == +3 && -7 % -2 == -1); // C++98 までは商 +4 余り +1 となる実装も規格適合
 }
 ```
 

lang/cpp11/right_angle_brackets.md

@@ -10,7 +10,7 @@
 <!-- last lang caution -->
 
 ## 概要
-C++03では、2つ以上連続する右山カッコが出現する場合には、間にスペースを入力する必要があった：
+C++98では、2つ以上連続する右山カッコが出現する場合には、間にスペースを入力する必要があった：
 
 ```cpp
 vector<basic_string<char> >; // OK
@@ -37,7 +37,7 @@ A<X>Y> b;   // コンパイルエラー
             // 2つ目の>トークンがoperator>()と見なされる。
 ```
 
-ただしこの仕様により、C++03までの以下のようなプログラムの動作が変更となる：
+ただしこの仕様により、C++98までの以下のようなプログラムの動作が変更となる：
 
 ```cpp example
 #include <iostream>
@@ -58,7 +58,7 @@ int main() {
 }
 ```
 
-C++03での出力：
+C++98での出力：
 
 ```
 0
@@ -89,7 +89,7 @@ int main()
 
 
 ## この機能が必要になった背景・経緯
-C++03までは構文解析の都合で、テンプレートの右山カッコが不等号やシフト記号と曖昧になっていた。そのためにテンプレートの右山カッコを明示する際には、2つの連続する右山カッコの間にスペースを必要とした。
+C++98までは構文解析の都合で、テンプレートの右山カッコが不等号やシフト記号と曖昧になっていた。そのためにテンプレートの右山カッコを明示する際には、2つの連続する右山カッコの間にスペースを必要とした。
 
 これは小さな問題ではあるが、永続的で迷惑な問題であったために、この問題を除去する価値があると判断され、GNUやEDGといったコンパイラベンダーによるいくつかの実験を経て、標準C++に、連続する右山カッコに関するルールが追加されることとなった。
 

lang/cpp11/rvalue_ref_and_move_semantics.md

@@ -45,7 +45,7 @@ int main()
 右辺値参照は、右辺値のみを束縛する参照である。  
 C++11からは、型`T`に対して `T&` で宣言される参照型を左辺値参照と呼ぶのに対して、`T&&` で宣言される参照型を右辺値参照と呼ぶ。
 
-C++03までは、右辺値のみを扱う右辺値参照は存在せず、右辺値はconst左辺値参照 `const T&` に束縛するよう扱われていた。  
+C++98までは、右辺値のみを扱う右辺値参照は存在せず、右辺値はconst左辺値参照 `const T&` に束縛するよう扱われていた。  
 このconst左辺値参照では左辺値も束縛できるため、左辺値／右辺値の区別情報が失われてしまい、右辺値のみに対して特別な処理を記述することができなかった。  
 
 ```cpp
@@ -54,7 +54,7 @@ v = vv;                  // 代入式1
 v = std::vector<int>(100, 0); // 代入式2
 ```
 
-上記コードはC++03では、代入式1,2ともに右辺は `vector<int> const&` 型に束縛される。  
+上記コードはC++98では、代入式1,2ともに右辺は `vector<int> const&` 型に束縛される。  
 代入処理の中では、右辺の値をコピーし、左辺の値と置き換えられる。  
 しかし代入式2の右辺は一時オブジェクトであり、直後に破棄されるため、一時オブジェクトをコピーすることは無駄といえる。  
 もし右辺値と左辺値を型を用いて区別できれば、右辺値の場合はコピーせず単に左辺と置き換えるといった処理が記述できる。  
@@ -373,7 +373,7 @@ enumの列挙子などもこれにあたる。
 
 
 ## この機能が必要になった背景・経緯
-ムーブセマンティクスは、C++03でもNRVO（特定の文脈でのコンストラクタの省略）や、
+ムーブセマンティクスは、C++98でもNRVO（特定の文脈でのコンストラクタの省略）や、
 C++11で非推奨となった`std::auto_ptr`で実現されていた。  
 しかし、NRVOがいつでも機能するわけではなかった。  
 また、`std::auto_ptr`にはコピーと同じ文法でムーブしていることなど、問題が多かった。  

lang/cpp11/scoped_enum.md

@@ -89,7 +89,7 @@ int main()
 
 
 ## この機能が必要になった背景・経緯
-C++03は、C99の列挙型に対する改善は提供していたが、依然として以下のような問題が残っていた：
+C++98は、C99の列挙型に対する改善は提供していたが、依然として以下のような問題が残っていた：
 
 - 型の安全性
 - 予期しないエラー(スコープがないことによる名前衝突、上記の型安全性の問題による予期しない型変換)

lang/cpp11/sfinae_expressions.md

@@ -14,7 +14,7 @@
 
 たとえば、関数のシグニチャの一部として「`typename T::value_type`」が書いてあり、型`T`が`value_type`という型を持っていない場合、その関数がオーバーロード解決から除外される。これによって型が任意の機能を持っているかを、コンパイル時に判定できた。
 
-しかしC++03において、SFINAEによって「型`T`に関する任意の式が有効かどうかを判定できるか」は仕様として曖昧だった。C++11ではこの曖昧さが取り除かれ、任意の式が有効かどうかでSFINAEが処理されることとなった。
+しかしC++98において、SFINAEによって「型`T`に関する任意の式が有効かどうかを判定できるか」は仕様として曖昧だった。C++11ではこの曖昧さが取り除かれ、任意の式が有効かどうかでSFINAEが処理されることとなった。
 
 ```cpp example
 #include <iostream>

lang/cpp11/user_defined_literals.md

@@ -337,7 +337,7 @@ hello
 
 ユーザー定義型に関して、C++には基本的な設計原則がある：
 
-1. ユーザー定義型は、組み込み型と同じ設備(facilities)をサポートできること。C++03では、組み込み型がもつ「リテラル」という機能を、ユーザー定義型に持たせることができなかった
+1. ユーザー定義型は、組み込み型と同じ設備(facilities)をサポートできること。C++98では、組み込み型がもつ「リテラル」という機能を、ユーザー定義型に持たせることができなかった
 2. C言語との互換性を維持する必要があるが、C99が持つ複素数リテラルを受け入れるための機能がない
 
 ユーザー定義型に対してリテラルを定義できるようにすることで、ユーザー定義型で可能な設計の範囲が増え、C言語が持つ複素数リテラルをC++の機能のなかで実現できるようになる。

lang/cpp14/sized_deallocation.md

@@ -10,7 +10,7 @@
 <!-- last lang caution -->
 
 ## 概要
-C++03ではクラス用の`delete`演算子として、サイズをとるバージョンをオーバーロードできた。C++14では、それに対応するグローバルの`delete`演算子を定義できるようにする。
+C++98ではクラス用の`delete`演算子として、サイズをとるバージョンをオーバーロードできた。C++14では、それに対応するグローバルの`delete`演算子を定義できるようにする。
 
 C++14では、オーバーロード可能なグローバルの`new`演算子、`delete`演算子として、以下を許可する：