キーワード (C++)とは

キーワード (C++)

キーワード (C++)は、プログラミング言語の1つであるC++のキーワード（予約語を参照）に関する説明。この項目は、プログラムの細かい説明には立ち入らず、他の言語と比較できるような説明を目的としている。

C++11には86のキーワードがある。最初に制定された規格であるC++98では73のキーワードが採用され、C++11で新たに13のキーワードおよび2つの文脈依存のキーワード（後述）が追加された。C++11から追加のキーワード及び機能には(*)を付す。C++14およびC++17ではキーワードは増えていない。

C89で存在したキーワードは、すべてがほぼそのままの形で取り入れられている。中には、codice_1など最初C++98に導入されたキーワードが後からC99にも導入されたものもある。codice_2は C11/C++11 両方に追加された。

Nullポインタ (null pointer) を表す。この値はあるcodice_3型のオブジェクトで、任意のポインタ型のNullポインタ値に暗黙変換できるが、整数リテラルcodice_4に置換される従来のcodice_5マクロとは異なり、整数型には暗黙変換できない。

複数のキーワードを組み合わせることで意味が変わるものが多い（文脈依存のキーワード）。

codice_6単体では符号付き短整数型codice_7を、codice_8単体では符号付き長整数型codice_9を意味する。codice_10は少なくとも64ビットの精度を持つ整数型である(*)。

codice_11は少なくともcodice_12と同じ精度を持つ浮動小数点数型。処理系によっては拡張倍精度浮動小数点数型となる。

C99ではマクロで定義されておりキーワードではないが、C++ではキーワードである。

codice_13は、Cではキーワードでないが、C++ではキーワードである。

codice_14とcodice_15は、それぞれUTF-16およびUTF-32の文字を格納するための整数型を表す。
変数宣言の際に型として指定すると、初期化式から型推論を行う。

また、戻り値型を後置きする関数宣言に用いる。

// 以下の2つは同じ宣言。
int main(int argc, char** argv);
auto main(int argc, char** argv) - int;

C++においてcodice_17はデフォルトのアクセス制御がcodice_18であること以外はcodice_19と全く同じである。codice_20もクラスの一種という扱いである。

codice_20はすべてのメンバ変数が同一メモリ領域を共有するのはCのままであるが、codice_19に準じてメンバ関数を持てるようになっている。

規格では、クラス内で宣言した変数および関数は、それぞれデータメンバーおよびメンバ関数と呼ぶ。JavaやC#のように、フィールド・メソッドなどといった用語は使われない。

codice_23単独ではスコープのない列挙型を意味する。codice_24、codice_25の形で、スコープ付きの列挙型の宣言に使用する(*)。

Cの書き換え不能という意味に加え、定数の意味が加わっている。具体的にはCと違いブロックスコープにない場合、定数扱いとなり、externを指定しない限り内部結合になる。プリプロセッサによるマクロの代替的手段になる。

const int N = 16;
int Array[N];

このコード片で、Cではcodice_26が定数ではないのでcodice_27の宣言はエラーになる。C99でもグローバル変数は可変長配列にできないのでやはりエラーになる。
クラス内では、整数型をcodice_28で修飾するとクラススコープの定数の定義になる。詳しくはstaticを参照のこと。

volatileの指定された記憶領域は、実行しているコードが書き換えを行わない場合にも、何らかの理由で内容が書き換えられる可能性を持つ。書き換えの起きる具体的な要因としては、何らかのハードウェアによる書き換えが挙げられる。

コンパイラによる最適化では、メモリを書き換えない限り内容が変わらないことを利用し、メモリからの再読み込みの省略などを行うが、例えばあるメモリ領域にハードウェアが書き込んでいて、そのメモリ領域の変化を読み取りループで監視しようとするならば、volatile指定が無い場合はコンパイラが「書き込みを行っていないのでメモリ内容が変化する可能性は無い」と判断し、ループを消し去ったり、メモリを再読み込みせずに単純な無限ループを行ったりするなど、期待と異なる最適化を行う可能性が高い。そのような場合、volatileを適切に指定することで、メモリ領域を正しくポーリングすることが期待できる。

また、コンパイラによっては、volatileの指定された記憶領域へのアクセス前後において、適切なメモリバリアを自動的に配置することもある。が、逆にメモリバリアについては一切関知しないものもあるため、ノンブロッキング同期プログラミングなどでは特別な注意が必要となる。

ハードウェアに近い操作を行う処理を記述する際は、特に重要になる修飾子である。

C++03以前では自動変数を意味する記憶クラス指定子であったが、C++11で廃止され、全く別の機能が割り当てられた。

関数内で定義した変数はデフォルトで自動変数となるため、C++03以前においても記憶クラス指定子としてのcodice_29を用いる必要は全くない。前方互換性のためにも無意味に使用すべきではない。なお、記憶クラスを指定しない変数の記憶クラスのを表す用語としては「自動変数」（auto変数）のままで変更はない。

Cからの外部結合の指定に加え、リンケージ指定の用法が加わっている。

C++では名前（関数名や変数名など）に対して多重定義や名前空間、型安全の保障などの都合から、多くのコンパイラは名前修飾を施しCとは異なった名前をリンカに対して用いている。その名前の修飾の仕方を指定するのがリンケージ指定である。少なくともCとC++の2種類のリンケージが使用できる。何も指定しないとC++になる。Cリンケージでは名前の変形を抑止しCと互換の名前をリンカに対して用いることを意味する。これによりCとC++を混在させてプログラムを作るときに使われる。

//a.cpp
extern C {
extern C int c; //リンケージ指定と元々の外部結合の意味を兼ねた用法。

//b.c
extern int a; //変数の宣言
int b; //変数の定義
int c;
void f()

また、codice_30の形でテンプレート実体化宣言を修飾して、外部で実体化されたテンプレートを指定する(*)。

C++17以降では何の機能もないキーワードである。将来のために予約されている。

C++14以前では、特にレジスタに割り当ててほしい自動変数に指定する記憶クラス指定子であった。Cよりも意味合いが弱く、Cのregister変数はアドレス参照（codice_31演算子によるポインタ取得）を行えないが、C++では行えた。つまり、register変数として宣言してもメモリに配置されうる。コンパイラが高度な最適化を行う場合、レジスタに配置すべき変数の判断はコンパイラの方が適切に行えることが多いので、C++14以前のコンパイラでも、この指定を無視するのが一般的であった。

特にクラスの場合、これは宣言となるため普通のグローバル変数などと同様にソースファイルで定義が必要である。ただし次の場合、例外として不要である。

//ヘッダbar.h
class bar
// static const double d = 2.0; //NG 整数型でない

//ソースbar.cpp

int bar::a = 1; //OK bar::aの定義

//const int bar::b = 5; //クラススコープの定数は定義する必要がない

const double bar::c = 3.0; //OK bar::cの定義

void bar::f() //OK bar::fの定義

古いC++処理系では整数型をcodice_28で修飾することによる定数の定義ができなかったので、代わりにクラス内の列挙 (enum) で代用をすることがしばしばあった。これはenumハックと呼ばれる。

C++11以降はcodice_33を併用することで、クラス宣言部で定数定義できる型が増加した。
グローバル変数やクラス・関数内静的変数について、スレッドローカルな記憶域に確保するよう指示する。

フレンド関数・フレンドクラスの宣言に用いる。
定数式を表す。変数や関数を修飾して、コンパイル時定数となりうることを指示する。
クラスメンバと継承のアクセス制御に用いられる。

Javaなどとは違い個々の宣言に付けるものではなく、見た目には関数内でラベルを指定するのと似ている。1度指定すると他の指定がなされるか、クラスの宣言が終わるまでは指定した制御が続く。

class foo
public:

protected:
}; //クラス宣言の終わりには ; が必要。

class hoge : private foo //private継承 外部からはhogeのインスタンスを通じてfooのメンバにはアクセスできない。
public:
自分自身へのポインタ。当然ながらクラスの非静的メンバ関数内でのみ使用できる。参照でなくポインタである理由は、thisがC++に導入された当時まだ参照がなかったからである

defaultは関数の定義にも用いる。特殊メンバ関数を「codice_37」の形で定義して、コンパイラ生成のものを使用することを明示する(*)。

newはヒープにオブジェクトを割り当てるnewとnew[]演算子に用いられ、deleteはそれを開放する演算子 deleteとdelete[]に用いられる（[]の有無で演算子は区別される）。JavaやC#などと違い、C++はガベージコレクションをもたないのでオブジェクトが不要になったら自分でdeleteを呼ぶ必要がある（スマートポインタを用いてdeleteの手間を省くようにすることはできる）。もっとも、C++には自動変数・大域変数などが存在するため、それほどnewは多用されない。

deleteは関数の定義にも使用される。関数を「codice_38」の形で定義して、そのシグネチャの関数を存在させないことを指示する(*)。

型変換（キャスト）は注意を要する操作であるにもかかわらず、Cの型変換演算子はあまりにも目立たず、目的がコードから見えにくいという理由からC++では、型変換を行う場合には用途ごとの4つの型変換演算子を用いることが推奨されている。

動的キャスト。RTTIを用いて、目的の型に変換できるかどうかを確認し、不可能であればポインタの場合Nullポインタを返し、参照の場合はbad_cast例外を投げる。また、Cに無い概念の為、Cの型変換演算子で代用できない。

静的キャスト。コンパイル時に型チェックを行う。変換前の型から変換後の型へ、あるいはその逆向きの暗黙の変換が存在する場合に変換可能である。変換できなければコンパイルエラーになる。

const/volatile性を取り除く場合に用いるキャストである。他のキャストでconst/volatile性が失われる変換はできない。

安全でなかったり移植性のない型変換に用いる。無関係なポインタ型同士の変換や、ポインタと整数型の変換などがそうである。

型のアライメントの値を得る。

式から型を取得し、型名として用いる。

型、あるいは式の型のサイズを得る。

また、codice_39の形で、可変長引数テンプレートの可変長引数部の長さを取得する(*)。

例外を投げる。また、後述の例外指定の用法もある（C++11以降でこの用法は非推奨）。

関数に例外指定を付与する。
//noexceptはどんな例外も投げないことを示す。
int func2() noexcept;

//noexceptはコンパイル時定数となる引数を取ることができ、trueならnoexceptと同じ。
int func3() noexcept(true);

//falseならあらゆる例外を投げる可能性がある。
int func4() noexcept(false);

//noexceptと等価な記述。
int func5() throw();

//noexcept(false)と等価な記述。
int func6() throw(...);

//この関数から投げられる例外はstd::exception型（とその派生クラス型）かint型しかありえないことを示す。この用法は非推奨。

C++11以降は、throwを用いた例外指定は推奨されない。C++03以前でも、throwを用いた例外指定は例外安全のうち例外を投げない表明としてfunc5のように型を無指定にして用いられる場合が大半であった。

また、noexceptは例外指定の有無を判定する式としても用いられる。

//b2はtrue
bool b2 = noexcept(func2()+1);
//b4はfalse
bool b4 = noexcept(func4()+func7());
コンパイル時に評価される表明を記述する。検査式が偽になると、指定されたメッセージを伴ってコンパイルエラーとなる。宣言として扱われるが、プログラムの動作には影響がない。

static_assert(sizeof(bar)==4, barのサイズが4ではありません);

//typenameの例
template typename T struct s1 //1の用法
};

用法2.はなぜ存在するのかというと、曖昧性が生じさせないためである。

たとえばs1に次のようなクラスをテンプレート引数に渡すとする。

struct s2

すると、仮にtypenameがなければs1s2::fの中の文はs2::type *ptr;となる。これはs2::typeとptrの乗算式と見られるので、構文としては正当なC++の式となってしまう（ただしこの例ではptrが宣言されていないためコンパイルエラーになる）。そうならないように、曖昧性を排除するために型名である場合はtypenameを先行させる仕様になっている。

C++11では何の機能もないキーワードである。将来のために予約されている(*)。

C++03以前では、分離コンパイルを行うクラス・関数テンプレートに指定するものであった。分離コンパイルとは、通常の関数などのようにヘッダに宣言を書いて、どこかのソースファイルに定義を書く形式のことである。これを指定しないとテンプレートは通常ヘッダに定義を書く必要がある。

このキーワードに対応しているコンパイラは、一般に広く知られたものではのみである。対応しない多くのコンパイラでは、このキーワードは単に無視されるか、キーワードとして扱われない場合さえある。

codice_40という構文が定まっているだけで、その文字列リテラルの書式等は処理系依存である。多くのコンパイラではインラインアセンブラを利用するために用いる。

変数宣言を修飾するアトリビュートで、変数のアライメントを指定する。

文脈依存のキーワード(contextual keyword)は、ソースコード中の特定の位置に現れた場合にのみキーワードとして扱われ、それ以外の箇所では単なる識別子として扱われる（変数名や関数名として使用出来る）。C++11から新たに追加された。

メンバ関数の宣言の直後、またはクラス宣言のクラス名の直後において文脈依存のキーワードとして扱われる。メンバ関数の宣言の直後では、その関数がオーバーライドされることを禁止する｡クラス名の直後では、そのクラスから派生すること（基底クラスとして用いられること）を禁止する。
メンバ関数の宣言の直後において文脈依存のキーワードとして扱われる。仮想関数が基底クラスのメンバ関数をオーバーライドすることを明示する。

代替字句(alternative token)のうちの、記号ではなくアルファベット（と下線）で表現する代替表現（alternative representation）は、キーワードには列挙されていないが、キーワードと同様に扱われる。ISO 14882の英語版の注ではlexical keywords（字句的にはキーワードであるもの）という表現が使われているが、JIS X 3014:2003の注では「予約語」という用語を用いて説明されている。

C/C++ではASCIIの記号類を多用しているので、ISO/IEC 646のUS以外を使用している環境では問題がある。それらの代用として、問題のない文字だけで表現するのが代替字句である（同じ用途のものとして他にトライグラフがある）。代替字句のうち、記号で表すダイグラフ（規格票の用語では「二つ組」）以外が代替表現である。これらはCではマクロ（ヘッダiso646.h、C95で標準化された）だが、C++では言語の一部である。

以下にそれぞれ対応する演算子を示してある。

C99 のキーワードのうち _Bool, _Complex, _Imaginary, restrict は C++ のキーワードではない。C11 で追加になったキーワードのうち _Alignas, _Atomic, _Generic, _Noreturn, _Static_assert, _Thread_local は C++ のキーワードではない。C99 の _Bool には C++ の bool が対応する。また、_Complex に関しては、代わりに std::complex クラステンプレートが標準C++ライブラリに存在する。

C++の次期規格C++20では、機能の追加に伴い、新しいキーワードの追加、既存のキーワードへの意味の追加が予定されている。

（基本型）UTF-8の文字を格納するための整数型を表す。
（新機能：コンセプト）コンセプトを定義する。コンセプトは、型が満たすべき要件に名前を与える新しいプリミティブである。
（関数指定子）変数や関数を修飾して、コンパイル時定数となることを指示する。codice_33と異なり、コンパイル時に評価することを強制する。
（新機能：コンセプト）テンプレート引数のコンセプト要求を指定する定数式を指定する。

（アトリビュート）codice_42, codice_43, codice_44のいずれかのアトリビュートの内部で、アトリビュート名の直後に出現した際に文脈依存のキーワードとして扱われる。これらのアトリビュートはそれぞれ関数についての事前条件、事後条件、不変条件の契約を示すための新しいアトリビュートである（契約プログラミング）。各アトリビュートの契約にはdefault, audit, axiomの三段階の契約レベルがあり、これらの文脈依存のキーワードはaudit契約レベルおよびaxiom契約レベルの指定に利用する（default契約レベルはキーワードcodice_45か、または指定を省略することによって指定する）。おおむね、defaultは実行時チェックの負荷が小さいもの、auditは実行時チェックの負荷が大きいもの、axiomは実行時チェックを意図しないものに指定することを規格では意図している。実際にどの契約レベルまで実行時にチェックするかは、「ビルドレベル」によって変更される。