インクリメント

インクリメント () は、一般には増加・増量・増分・増大という意味だが、コンピュータ用語としては、変数の値を1増やす演算のことである。
逆に、1減らす演算はデクリメント () という。
概要.
インクリメント操作はループにおけるカウンタの増減や、逐次アドレッシングなどで使用頻度が極めて高いため、プロセッサレベルで専用の命令が用意されていることが多い。また、プログラミング言語のレベルでも、インクリメントをするときのための「インクリメント演算子」が用意されていることが多い。さらに、コンパイラのレベルでも、インクリメント演算子に対して最適化してくれる場合が多い。その場合、算術演算子（C言語ではcodice_1）や累算代入（複合代入）演算子（codice_2）を使うよりもインクリメント演算子（codice_3）を使ったほうが、コンパイラがプロセッサのインクリメント命令を使うようなコードを生成してくれて高速になる可能性が高い。
しかし、「加算/減算」という概念とは別に「インクリメント/デクリメント」という概念を扱うのは初心者にとって煩雑になり、ある程度慣れたプログラマであっても演算子の評価順序を見誤るとバグの元となる場合がある。またマイコンレベルでも必須というわけではないため、インクリメント命令を搭載しない場合がある。また、コンパイラの最適化が進んでいた場合、インクリメントを使っても算術演算子を使っても、どちらも同じ（最も速くなる）機械語を生成するので、現代の主要な開発環境およびコンパイラを使っている場合は、あえてインクリメントを使って処理速度を稼ぐ必要はない。そのため、インクリメントという概念をあえて排除する場合もある。例えば、情報処理技術者試験で用いられる仮想計算機COMET IIの命令セットにはインクリメント命令が存在しない。また、プログラミング言語のPythonにも存在しない。Pascalにはインクリメント演算子がないが、Object Pascal（Delphi）にはcodice_4手続きが存在し、場合によっては最適化されたコードに置き換えられる。
プロセッサでの扱い.
通常、レジスタに数値を加算するには、1ワードで加算命令とレジスタを表し、もう1ワードで加算する数値を表すので、計2ワードが必要だが、インクリメント命令を使えば1ワードで済む。ただし、プロセッサによっては、インクリメント命令は加算命令よりもオペランドの種類が限られる（たとえばアキュムレータのみに可能など）。
アセンブラの中には、1を加算する加算命令をインクリメント命令に最適化するものもある。
高水準言語での扱い.
C言語、C++、Java、JavaScriptなどでは、インクリメント（増分）演算子「codice_3」が用意されている。前置インクリメントと後置インクリメントの2種類がある。字句は同じ「codice_3」だが、前置演算子として使うか（例: codice_7）後置演算子として使うか（例: codice_8）で意味が違う。オペランドが数値型（整数型、浮動小数点数型）の場合は1だけ値が変わり、またポインタ型の場合は指し示す対象型の値1個分だけアドレスが変わるのはどちらも同じだが、式としての値が、前置の場合はインクリメントした後の値になり（この意味はcodice_9と同じ）、後置の場合はインクリメントする前の値になる。
y = ++x; // y = (x += 1); と同じ
y = x++; // y = x; x = x + 1; と同じ
C++の演算子オーバーロードでは、通常の記法では前置インクリメントと後置インクリメントを区別できないので、便宜上、後置インクリメントには余分なcodice_10型引数を記述して区別する。ただし、C++コンパイラはこの後置インクリメントの宣言に対応していないことがある。
T& class T::operator++() { *this += 1; return *this; } // 前置インクリメントのオーバーロード
T class T::operator++(int) { T old = *this; *this += 1; return old; } // 後置インクリメントのオーバーロード
デクリメント演算子「codice_11」も同様である。
真理値とインクリメント.
アセンブリ言語（アセンブラ）や初期のプログラミング言語は、真理値を表す専用のデータ型（ブーリアン型）を持たず、整数型で代用することが多かった。整数で代用する場合、通例0を偽 (false) として扱い、また0以外をすべて真 (true) として扱う。C言語はこの仕様を引きずっており、論理演算の結果は基本整数型codice_10となる。これはANSI C（C89）以前だけでなく、組み込みのブーリアン型codice_13が追加されたC99以降も変わらない。
このようにブーリアン型として整数型を使用すると、本来インクリメントで記述する必要がない（インクリメントで記述してはいけない）コードにも、誤って使われてしまうことがある。例えば真理値を表すフラグ変数の値を偽から真に変更する場合、通常は変数に何らかの固定値（一般的な代表値としては1）を代入する。しかし、整数型では0をインクリメントすると1になることから、代入ではなくインクリメントでも偽から真に変更することができてしまう。
ソフトウェア工学や安全工学の未発達な時代に、不適切なインクリメント命令の使用が致命的なバグを生み、重篤な事故を引き起こした事例として、放射線療法機器のセラック25が挙げられる。セラック25は1985年から1987年にかけて知られる限り6つの重大な被曝事故を引き起こし、少なくとも5人の患者を死亡させた。事故原因には複数の要因があるが、まずセラック25は従来機に搭載されていた電気機械式の安全保護装置（ハードウェア・インターロック）を取り除き、（当時はハードウェア制御よりも安全だと思われていた）ソフトウェア制御に置き換えてしまっていた。装置を制御するコンピュータPDP-11のオペレーティングシステムにおいて、安全性を確保するためのソフトウェア・インターロックのひとつに使われていた、Class3と呼ばれるフラグ変数は、値が0以外の場合、装置に何らかの不一致があり、放射線治療を続行できないことを意味するものだった。セットアップテストのルーチンを通過するたびにClass3変数の値がインクリメントされるコードになっていたが、このClass3変数は1バイト（1オクテット）であり、十進数で0から255までの数値しか表現できない。値が255のときにインクリメントしてしまうと、オーバーフローが発生して0に戻ってしまう。この異常動作はセットアップテストを256回通過するたびに発生する。つまり、本来はフラグが真でなければならない場面で偽となり、障害が正しく検出されないというバグが存在していた。これにより、装置の安全チェックがバイパスされてしまい、患者に過度の放射線が照射され、患者が死亡する可能性があった。当初セラック25のメーカーはこのバグに気づかず、「事故は起こりえない」と回答したことが被害を拡大させた。
なお、Cとは異なり、C++には、ISO規格として標準化される前にリリースされた段階でcodice_14型が存在していた。C++98規格として標準化された時点で、このcodice_14型は値としてcodice_16 (codice_17) あるいはcodice_18 (codice_19) のみをとることが保証されるようになった（とはいえ、すべてのC++実装がこの規格で定められた仕様に正しく準拠していたわけではない）。また、codice_14型の値をどれだけインクリメントしてもcodice_18となるように定められていたが、codice_14に対するインクリメントはC++98の時点で非推奨となっていた（この仕様決定にセラック25の教訓が反映されていたかどうかは定かではない）。その後、C++17で、インクリメント演算子「codice_3」がcodice_14型に適用できないように規定され、codice_14型へのインクリメントは正式に削除された。
JavaやC#のような後発の安全な言語では、ブーリアン型へのインクリメントは登場当初から禁止されている。
ネーミングでの使用.
C++、Notepad++のように、改良版であることを示すためにインクリメント演算子「++」をつけることがある。
「」の形容詞形「」は、インクリメンタルサーチやインクリメンタルビルド（増分ビルド）といったソフトウェア機能の名称に使われることもある。