JavaとC++の比較

• Javaの構文は文脈自由文法を採用しており、シンプルなLALRパーサーで解析できます。C++の解析はより複雑です。例えば、は が変数でFoo<1>(3);あれば比較のシーケンスになりますが、 がクラステンプレートの名前でFooあればオブジェクトを作成します。Foo
• C++では、名前空間レベルの定数、変数、関数が使用できます。Javaでは、これらのエンティティは特定の型に属する必要があり、そのため、クラスまたはインターフェースといった型定義内で定義する必要があります。
• Javaでは、すべての型は名前空間（Javaパッケージ）に属し、C++のように名前空間に属さないコードがグローバル名前空間の一部となるような「グローバル名前空間」は存在しません（コードがどのクラスにも属していないように見えるコンパクトなソースファイルであっても、そのようなコードは最終的に無名パッケージ内のトップレベルクラスに属します）。Javaでは、「無名パッケージ」はグローバル名前空間ではなく、その中のクラスは名前付きパッケージ内のコードからインポートすることはできません。
• Javaには厳密なグローバル継承ツリーがあり、すべてのクラスは（暗黙的に）最上位型を継承します。C java.lang.Object++にはグローバル継承ツリーはありません。最上位型はありますが、継承型ではなく、型消去されたstd::anyランタイムオブジェクトです。
• C++ではオブジェクトは値ですが、Javaではそうではありません。C++はデフォルトで値セマンティクスを使用しますが、Javaは常に参照セマンティクスを使用します。C++で参照セマンティクスを選択するには、ポインタまたは参照のいずれかを使用できます。

• C++ は文をサポートしていますが、これはスパゲッティコードgotoプログラミングにつながる可能性があります。goto 文 (実際のコードではほとんど見られず、強く推奨されません) を除けば、Java と C++ は基本的に同じ制御フロー構造を持ち、構造化された制御フローを強制するように設計されており、break 文と continue文を使用していくつかの類似の機能を提供します。一部のコメントでは、これらのラベル付きフロー制御文が構造化プログラミングの単一出口特性を破ると指摘されています。^{[ 11 ]}goto
• C++は、Javaにはほとんどない低レベル機能を提供します（ただし、sun.misc.Unsafeメモリへの直接アクセスと操作のための内部APIは例外です）。C++では、ポインタを使用して特定のメモリ位置を操作できます。これは、低レベルのオペレーティングシステムコンポーネントを作成する際に必要な機能です。同様に、多くのC++コンパイラはインラインアセンブラをサポートしており、アセンブリ関数をC/C++プログラムにリンクできます。Javaでは、このようなコードは外部ライブラリに格納する必要があり、Java Native Interfaceを介してのみアクセスできますが、呼び出しごとにかなりのオーバーヘッドが発生します。

• C++では関数／メソッドの引数にデフォルト値を設定できますが、Javaではできません。ただし、 Javaではメソッドのオーバーロードを使用することで同様の結果を得ることができますが、冗長なスタブコードが生成されます。
• C++のコンパイルに必要な最小限のコードは関数であり、Javaの場合はクラスです。しかし、Java 21以降、無名クラスが導入されたことで、main関数のみで構成されるJavaプログラムを作成することが可能になりました。
• C++では、ネイティブ型間の暗黙的な型変換（一部の縮小型変換を含む）が幅広く許可されており、ユーザー定義型を含む暗黙的な型変換を定義することもできます。Javaでは、ネイティブ型間の拡大型変換のみが暗黙的に許可されており、その他の型変換には明示的なキャスト構文が必要です。
  • その結果、Java と C++ のループ条件 ( if、whileおよび の終了条件for) はどちらもブール式を期待しますが、 のようなコードは、int から Boolean への暗黙的な縮小変換がないため Java ではコンパイル エラーになりますが、C++ ではコンパイルされます。これは、コードがタイプミスで意図的なものであった場合に便利です。ただし、現在の C++ コンパイラは、条件式内でこのような代入が行われると、通常は警告を生成します。同様に、副作用のない単独の比較文 ( など) も通常は警告につながります。if(a=5)if(a==5)a == 5;
• 関数にパラメータを渡す場合、C++ は参照渡しと値渡しの両方をサポートしています。Java では、プリミティブ型のパラメータは常に値渡しされます。クラス型、インターフェース型、配列型は、Java ではまとめて参照型と呼ばれ、常に値渡しされます。^{[ 12 ] [ 13 ] [ 14 ]}
• Javaの組み込み型は、言語仕様で定義された特定のサイズと範囲を持ちます。C++では、組み込み型に対して最小値の範囲が定義されていますが、正確な表現（ビット数）は、特定のプラットフォームで優先されるネイティブ型にマッピングできます。
  • 例えば、Javaの文字は16ビットUnicode文字であり、文字列はそのような文字の連続で構成されます。C++は狭幅文字と広幅文字の両方を提供しますが、それぞれの実際のサイズはプラットフォームに依存し、使用される文字セットも同様です。文字列はどちらのタイプからも作成できます。
  • これはまた、C++コンパイラがターゲットプラットフォームに対して最も効率的な表現（例えば、64ビットプラットフォームの場合は64ビット整数）を自動的に選択できるのに対し、Javaでは表現が固定されているため、値は効率の悪いサイズで格納されるか、残りのビットをパディングして、縮小幅の動作をエミュレートするコードを追加する必要があることを意味します。
• C++ の浮動小数点値と演算の丸めと精度は実装依存です (ただし、IEEE 754標準から逸脱するのは非常に特殊なプラットフォームまたは古いプラットフォームのみです)。Java は、実行時のパフォーマンスが低下する可能性があるものの、プラットフォーム間でより一貫した結果を保証するオプションの厳密浮動小数点モデル( strictfp) を提供します。ただし、Java は IEEE 754 標準に厳密には準拠していません。ほとんどの C++ コンパイラは、デフォルトでは IEEE 754 に部分的に準拠しますが (通常は厳密な丸めルールを除外し、NaN の結果に対して例外を発生させます)、最適化を可能にするために、さまざまな厳密さの準拠オプションを提供します。^{[ 15 ] [ 16 ]}これらのオプションを準拠度の低いものから高いものへとfast、consistent (Java のstrictfp )、near-IEEE、strict-IEEEとラベル付けすると、ほとんどの C++ 実装はデフォルトでnear-IEEEであり、 fastまたはstrict-IEEEに切り替えるオプションがあるのに対し、Java はデフォルトでfastであり、 consistentに切り替えるオプションがあると言えます。
• C++ では、ポインタはメモリ アドレス値として直接操作できます。Java の参照はオブジェクトへのポインタです。^{[ 17 ]} Java の参照では、メモリ アドレスへの直接アクセスや、ポインタ演算によるメモリ アドレスの操作はできません。C++ では、ポインタへのポインタ、int 型と double 型へのポインタ、任意のメモリ位置へのポインタを作成できます。Java の参照はオブジェクトにのみアクセスし、プリミティブ型、他の参照、任意のメモリ位置にはアクセスしません。Java では、API を使用して任意の値でメモリを読み書きできますがsun.misc.Unsafe、これは非推奨であり、推奨されません。
• C++では、ポインタは関数またはメンバ関数（関数ポインタ）を指すことができます。Javaにおける同等の仕組みは、オブジェクト参照またはインターフェース参照を使用します。
• C++ はスタックに割り当てられたオブジェクトを介してスコープ付きリソース管理をサポートしています。これは、メモリやその他のシステム リソースを自動的に管理し、決定論的なオブジェクト破棄をサポートする手法です。C++ のスコープ付きリソース管理は保証できません (適切なデストラクタを持つオブジェクトでも を使用して割り当てられnew、削除されないままになる可能性があります) が、効果的なリソース管理手段を提供します。共有リソースは を使用して管理できstd::shared_ptr<T>、循環参照を解消するには を使用します。Java は、ガベージ コレクション^{[ 7 ]}std::weak_ptr<T>を使用した自動メモリ管理をサポートしており、循環参照が存在する場合でも到達不能なオブジェクトを解放できますが、ガベージ コレクションは最後のオブジェクト参照が破棄された直後に発生することが保証されていないため、他のシステム リソース (ファイル^{[ 5 ]}ストリーム、ウィンドウ、通信ポート、スレッドなど) は明示的に解放する必要があります。Java は、を実装する型に対して -with-resources ブロックを介してスコープ リソース管理を許可しますが、C++ とは異なり、オブジェクトはメモリから破棄されず、所有するリソースのみがメソッドによって破棄されます。tryjava.lang.AutoCloseableclose()
• C++ には、ユーザー定義演算子オーバーロード機能があります。演算子オーバーロードにより、ユーザー定義型は、これらの演算子のユーザー定義実装を介して、プリミティブ型と同様に演算子（算術演算子、比較演算子など）をサポートできます。一般的には、演算子のセマンティクスを維持することが推奨されます。Java は、いかなる形式の演算子オーバーロードもサポートしていません（ただし、Java ライブラリでは文字列連結に加算演算子を使用しています）。
• Javaは、リフレクションプログラミング（リフレクション）と任意の新規コードの動的ロードのための標準的なアプリケーションプログラミングインターフェース（API）をサポートしています。
• C++はバイナリの静的リンクと動的リンクをサポートしています。
• JavaとC++（C++26以降）はどちらもリフレクションを提供しており、ある程度のコード内省が可能となっている。Javaのリフレクションは主に実行時に動作し、主に振る舞いを制御するものである一方、C++のリフレクションはコンパイル時に動作し、メタオブジェクトを生成するため、主に生成的な性質を持つ。
• Javaにはジェネリクスがあり、その主な目的は型安全なコンテナを提供することです。ただし、Javaのジェネリクスは具体化されず（コンパイル時のみ動作）、実行時には型消去されます。C++にはコンパイル時テンプレートがあり、ジェネリックプログラミングとメタプログラミングをより広範にサポートします。C++テンプレートは、使用される各型に対して特殊化をインスタンス化します。
• JavaとC++はどちらもアノテーションを提供しています。Javaのアノテーションを使用すると、クラスに任意のカスタムメタデータを追加したり、アノテーション処理ツールを介してメタプログラミングを行うことができます。C++は、コンパイラ定義のメタデータを示す属性に加え、（C++26以降）アノテーションも提供しています。アノテーションはユーザーが定義でき、コンパイル時に読み取ることができますが、Javaのように実行時に読み取ることはできません。
• JavaとC++はどちらも、ネイティブ型（基本型または組み込み型とも呼ばれる）とユーザー定義型（複合型とも呼ばれる）を区別します。Javaでは、ネイティブ型は値セマンティクスのみを持ち、複合型は参照セマンティクスのみを持ちます。C++では、すべての型が値セマンティクスを持ちますが、任意の型への参照を作成することができ、参照セマンティクスを介してオブジェクトを操作できます。
• C++ は任意のクラスの多重継承をサポートしています。Java では、クラスは 1 つのクラスからのみ派生できますが^{[ 1 ]} 、クラスは複数のインターフェースを実装できます^{[ 18 ]} (言い換えれば、型の多重継承はサポートしていますが、実装の単一継承のみをサポートしています)。
• Javaでは、インターフェースとクラスが明確に区別されています。C++では、多重継承と純粋仮想関数を用いることで、Javaのインターフェースとほぼ同じように機能するクラスを定義することが可能です。ただし、いくつかの小さな違いがあります。
• Java は、言語と標準ライブラリの両方でマルチスレッドをサポートしています。Javasynchronizedのキーワードは、マルチスレッドアプリケーションをサポートするミューテックスロックを提供します。 ^{[ 19 ] [ 20 ]} Java は、より高度なマルチスレッド同期のためのライブラリも提供しています。C ++11では、C++ でのマルチスレッド用に定義されたメモリモデルがあり、スレッドの作成や多くの同期プリミティブのためのライブラリサポートがあります。
• C++ のメンバ関数は仮想関数として宣言できます。これは、呼び出されるメソッドがオブジェクトの実行時型によって決定されることを意味します (動的ディスパッチとも呼ばれます)。デフォルトでは、C++ のメソッドは仮想ではありません (つまり、オプトイン仮想)。Java では、メソッドはデフォルトで仮想ですが、キーワードを使用することで非仮想にすることができますfinal(つまり、オプトアウト仮想)。
• overrideC++には、仮想メソッドのオーバーライドを示す言語レベルのキーワードがあります。Javaにはそのようなキーワードはありませんが、@Overrideオーバーライドを示すための注釈があり、既存のメソッドがオーバーライドされていない場合はコンパイラエラーが発生します。
• C および C++ の列挙型はプリミティブ型です。C の列挙型 ( enum) は暗黙的に整数型に変換されます (ただし、整数型からの変換はできません)。一方、C++ の列挙型 ( enum class) は厳密に型付けされており、暗黙的な変換は行われません。Java の列挙型はクラスのように動作し、コンストラクタやメソッドを定義できます。
• C++ の単項演算子++と--: は「オペランドは変更可能なlvalueでなければならない。[省略] 結果は更新されたオペランドであり、lvalue である...」^{[ 21 ]}ですが、Java では「上記のバイナリ数値昇格には、アンボックス化変換と値セット変換が含まれる場合があります。必要に応じて、合計が変数に格納される前に、値セット変換 {および/または [...] ボックス化変換} が適用されます。」^{[ 22 ]}つまり、Java では初期化後に新しいオブジェクトを割り当てることで参照が変更されますが、C++ ではオブジェクトは依然として同じです。Integeri=2;++i;i
• Java では、ラムダは「多項式」であり、その型はコンテキストに依存します^{[ 23 ]}。一方、C++ では、ラムダは実際の実行時クラスを持ち、それを使用してアクセスできdecltype、言語モデルの一部です。Java のラムダは、割り当てられた関数インターフェースに依存します。

• Javaは自動ガベージコレクションを提供しますが、リアルタイムJava仕様によって特定の状況下ではこれをバイパスできます。C++のメモリ管理は通常、コンストラクタ、デストラクタ、およびスマートポインタによって行われます。C++標準ではガベージコレクションが許可されていますが、必須ではありません。ガベージコレクションは実際にはほとんど使用されていません。
• C++では任意のメモリブロックを割り当てることができます。Javaではオブジェクトのインスタンス化によってのみメモリを割り当てます。Javaでは、任意のメモリブロックをバイト配列として割り当てることができます。
• JavaとC++は、リソース管理に異なるイディオムを使用しています。Javaは主にメモリを解放できるガベージコレクションに依存していますが^{[ 7 ]}、C++は主にリソース取得は初期化である（RAII）イディオムに依存しています。これは、2つの言語間のいくつかの違いに反映されています。
  • C++では、複合型のオブジェクトをローカルなスタック変数として割り当て、スコープ外になると破棄するのが一般的です。Javaでは、複合型は常にヒープに割り当てられ、ガベージコレクタによって回収されます（ただし、エスケープ解析を使用してヒープ割り当てをスタック割り当てに変換する仮想マシンは除きます）。
  • C++ にはデストラクタ^{[ 7 ]}があり、 Java にはファイナライザ^{[ 7 ]}があります。どちらもオブジェクトの解放前に呼び出されますが、大きく異なります。C++ オブジェクトのデストラクタは、オブジェクトを解放するために暗黙的に (スタックにバインドされた変数の場合) または明示的に呼び出される必要があります。デストラクタは、プログラム内でオブジェクトが解放される直前に同期的に実行されます。したがって、C++ での同期的かつ協調的な初期化解除と解放は、RAII イディオムを満たします。C++ のデストラクタは、オブジェクトに関連付けられたリソースを取り戻す通常の方法であり、コンストラクタの必要な対義語です。^{[ 7 ]} Java では、オブジェクトの解放はガベージ コレクタによって暗黙的に処理されます。Java オブジェクトのファイナライザは、最後にアクセスされてから解放される前に、非同期的に呼び出されます。ファイナライザを必要とするオブジェクトはごくわずかです。ファイナライザは、解放前にオブジェクト状態のクリーンアップを保証する必要があるオブジェクト、通常は JVM の外部のリソースを解放するオブジェクトにのみ必要です。^{[ 7 ]}ファイナライザを直接使用することは、予測不可能で、通常は危険であり、ほとんどの場合不要であるため、通常は推奨されません。^{[ 7 ]}ファイナライザを C++ デストラクタのように考えないように注意する必要があります。^{[ 7 ]}むしろ、try-with-resources またはtry-finallyブロックの方が、デストラクタと似た目的を達成します。^{[ 7 ]}ファイナライザまたはクリーナーの問題の 1 つは、すぐに実行されることが保証されていないことです。^{[ 7 ]}したがって、ファイナライザは、時間的に重要なタスクには決して使用しないでください。^{[ 7 ]}さらに、ファイナライザは深刻なパフォーマンス ペナルティを伴い、オブジェクトの解放にかかる時間を大幅に増加させるため、Java 9 ではその使用は推奨されず、非推奨となっています。
  • C++ の RAII では、通常、1 種類のリソースが小さなクラスでラップされ、構築時にリソースを割り当て、破棄時にリソースを解放し、その間のリソースへのアクセスを提供します。このような RAII オブジェクトのみを含むクラスは、デストラクタを定義する必要はありません。なぜなら、このクラスのオブジェクトが破棄されると、RAII オブジェクトのデストラクタが自動的に呼び出されるからです。Java では、try- catch-finally構文を使用して、リソースの安全な同期解放を決定論的に実行できます。あるいは、 Java 7 で導入された -with-resources 構文を-構文tryよりも優先して使用する必要があります。^{[ 24 ]} try-with-resources 構文は、より簡潔で読みやすいです。^{[ 24 ]}また、抑制された例外は破棄されず、抑制されたことを示す情報とともにスタック トレースに出力されるため、より役立つ診断情報も提供されます。^{[ 24 ]}tryfinally
  • C++では、既に解放されたオブジェクトへの無効な参照である「ダングリングポインタ」が存在する可能性があります。ダングリングポインタを使用しようとすると、通常はプログラムが失敗します。Javaでは、ガベージコレクタは参照されているオブジェクトを破棄しません。
  • C++では、初期化されていないプリミティブオブジェクトが存在する可能性がある。Javaでは、デフォルト初期化が強制される。
  • C++ では、有効な参照がない割り当て済みオブジェクトが存在する可能性があります。このような到達不能なオブジェクトは破棄 (解放) できず、メモリ リークが発生します。一方、Java では、オブジェクトは(ユーザー プログラムから) 到達不能になるまでガベージ コレクタによって解放されません。 (弱い参照がサポートされており、Java ガベージ コレクタと連携して、到達可能性の強度を様々に調整できます。) Java のガベージ コレクションは多くのメモリ リークを防止しますが、状況によってはリークが発生する可能性は依然としてあります。^{[ 25 ] [ 26 ] [ 27 ]}自動ガベージ コレクタにより、Java ではメモリ管理について考える必要がないという誤った印象を与えるかもしれません。^{[ 5 ]}しかし、これは必ずしも正しくありません。^{[ 5 ]}大まかに言えば、これはプログラムが「メモリ リーク」、より正式には「意図しないオブジェクト保持」を持つ可能性があるためです。^{[ 5 ]}メモリリークが発生する例として、古い参照を削除しなかったことを除いて論理エラーのないプログラムが挙げられます。^{[ 5 ]}これにより、ガベージコレクタのアクティビティの使用が増加し、メモリ使用量が増加します。^{[ 5 ]}極端な状況では、この問題により が発生することがありますjava.lang.OutOfMemoryErrorが、これはまれです。

^{[ 5 ]}この解決策は、オブジェクト参照を null にすることです。 ^{[ 5 ]}メモリ リークの 2 つ目の一般的な原因は、もはや関連性がなくなったキャッシュの使用です。古いキャッシュの使用によるメモリ リークの解決策は、キャッシュを を使って表現することですjava.util.WeakHashMap<K, V>。

• C++は、通常プラットフォーム固有のライブラリで提供される多くの機能へのクロスプラットフォームアクセスを提供します。Javaからネイティブオペレーティングシステムおよびハードウェア機能に直接アクセスするには、 Java Native Interface、またはJava 21以降ではForeign Function and Memory APIを使用する必要があります。これらを使用すると、Java仮想マシンの外部でメモリを割り当てて管理したり、ネイティブ（つまりC/C++）関数を呼び出したりすることができます。
• C ++標準ライブラリは最小限の設計となっており、標準化された汎用機能のみを提供していますが、JavaクラスライブラリとJavaプラットフォームモジュールシステム（Java標準ライブラリ）ははるかに広範で、グラフィックス、UI作成など、より包括的で標準化された機能セットを提供しています。

• C++ は表現力に制約がないため、低レベルの言語機能 (配列へのアクセスチェックなし、生ポインタ、型変換など) はコンパイル時に確実にチェックすることも、実行時にオーバーヘッドなしでチェックすることもできません。関連するプログラミングエラーは、低レベルのバッファオーバーフローやセグメンテーション違反につながる可能性があります。標準テンプレートライブラリ(STL) は、このようなエラーを回避するために、高レベルの RAII 抽象化 (vector、list、map など) を提供します。Java では、低レベルのエラーは発生しないか、 Java 仮想マシン(JVM)によって検出され、例外の形式でアプリケーションに報告されます。
  • Java ランタイムでは例外が密接に結合しており、言語レベルの操作 (ゼロ除算、ヌル参照アクセス、無効なキャスト、範囲外配列アクセスなど) は例外をスローする可能性がありますが、C++ では通常、オブジェクトのみが例外をスローします (例外をスローする可能性がある^{[ 28 ]}、例外をtypeid()スローする可能性があるまたは^{[ 29 ]}、例外をスローする可能性がある、例外をスローする可能性がある^{[ 30 ]}を除く)。さらに、C++ では例外を「無効」にすることができます ( GCCやClang ^{[ 31 ]}の、またはMSVCのなど)。これにより、コンパイラが例外処理用のコードを生成しなくなり、ステートメントでプログラムを で終了します。std::bad_typeidnewstd::bad_allocstd::bad_array_new_lengthnewstd::bad_allocdynamic_caststd::bad_cast-no-exceptions/Ehscstd::terminate()throw
  • Javaにはチェック例外という機能があり、これはブロック内で処理されなければならない例外でcatch、明示的に宣言された例外のみが関数を通して伝播できますthrows。例外を拡張しない例外はすべてjava.lang.RuntimeExceptionチェック例外とみなされます。一方、C++には「チェック例外」という概念はありませんが、関数は指定子をnoexcept使用して例外をスローしないように指定できます。C++17までは、C++はthrow関数シグネチャの例外指定によって動的な例外指定を許可しており、これはJavaのthrows例外指定と同様に、関数がスローできる型を指定できるようにしていました。^{[ 32 ]}
  • java.lang.ThrowableJava では、例外ステートメントによってスローされるのは、拡張クラスのみが許可されますthrow。C++ では、プリミティブ型を含むあらゆるオブジェクトがスローされ、キャッチされる可能性があります。Java では、java.lang.Error(キャッチするのが不適切と考えられる実行時エラーを表す) とjava.lang.Exception(キャッチするのが適切と考えられる回復可能なエラーを表す) を区別しますが、C++ では、通常の基本例外クラスは ですstd::exception。
• Java 言語では、配列の範囲外アクセスの場合に特定の動作が要求され、一般的に配列アクセスの境界チェックが要求されます。これにより不安定性の原因となる可能性のあるものが排除されますが、通常は実行速度の低下という代償を伴います。場合によっては、特に Java 7 以降では、コンパイラ分析によって境界チェックが不要であることが証明され、それが削除されることがあります。C++ ではネイティブ配列の範囲外アクセスに対する必須の動作がないため、ネイティブ配列の境界チェックは不要です。std::vector<T>ただし、C++ 標準ライブラリのコレクションなどでは、オプションの境界チェックが提供されます。要約すると、Java 配列 ( T[]) は「通常は安全、わずかに制約あり、オーバーヘッドが多い」のに対し、C++ ネイティブ配列は「オプションのオーバーヘッドあり、わずかに制約なし、安全でない可能性がある」です。Java コレクションなどでは、java.util.ArrayList<T>などの例外がスローされることがありますjava.lang.IndexOutOfBoundsException。C++26 では、標準ライブラリに「境界強化」が追加され、特定の未定義動作(範囲外アクセスを含む) が契約違反として定義されるようになりました。^{[ 33 ] [ 34 ]}

C++とJavaはどちらも、それぞれテンプレートとジェネリクスという汎用プログラミングのための機能を提供しています。両者は似たような問題を解決するために開発され、構文も似ていますが、実際にはかなり異なっています。

• JavaとC++は、コードを複数のソースファイルに分割する方法が異なります。
  • Javaは、すべてのプログラム定義のファイル名とパスを規定するパッケージシステムを使用します。コンパイラは実行可能なクラスファイルをインポートします。
  • C++20以前は、C++はヘッダーファイルによるソースコードインクルードシステムを用いて、ソースファイル間で宣言を共有していました。しかし、C++20以降は、 Javaパッケージと同様の機能を提供するモジュールが導入されました。マークされたシンボルはすべて、exportモジュールをインポートした後にアクセスできます。
  • C++23以降、C++標準ライブラリをモジュールとしてインポートできるようになりました。
• 「モジュール」という用語は、異なるものを指します。Javaでは、モジュールは複数のパッケージをグループ化するために使用されますが、C++では、モジュールとして宣言された 単一の翻訳単位を表します。
  • importC++ では、コンパイル時に BMI (ビルド済みモジュールインターフェース) をロードすることでモジュールをインポートしますが、C++ では、モジュールはシンボルが属する名前空間を規定しません。一方、importJava では、クラスをエイリアスして完全修飾を避けるため (C++ の に相当)、コンパイル時に定義を「インポート」しません。これは、すべてのクラスが実行時に必要に応じてJava クラスローダーusingによって処理され、完全修飾することで ステートメントなしでも使用できるためです。import
• Javaソースファイルは、宣言するパブリッククラスの名前空間と一致している必要があり（パブリッククラスがない場合は任意の名前を使用できます）、また、そのファイルが属するパッケージは、そのファイルのパスと一致している必要があります。パッケージは、最大で1つのパブリッククラスしか宣言できません（ただし、複数の非パブリッククラスを持つことができます）。
• C++ソースファイル（ヘッダーファイルまたはモジュールファイル）は、任意の名前を持つことができ、プログラマーが望む数のクラスを含めることができます。モジュールは、その場所のパスと一致する必要はありません。
• コンパイルされたJavaクラスファイルは、一般的にC++のオブジェクトファイルよりも小さくなります。これは、 Javaバイトコードが通常ネイティブマシンコードよりもコンパクトであり、Javaは静的リンクを行わないためです。
• C++のコンパイルにはテキストの前処理フェーズが追加されているが、Javaにはない。そのため、条件付きコンパイルをより適切にサポートするために、ビルドプロセスに前処理フェーズを追加するユーザーもいる。
• Java の除算演算子と剰余演算子は、ゼロに切り捨てるように明確に定義されています。C ++11より前は、C++ ではこれらの演算子がゼロに切り捨てるか「負の無限大に切り捨てる」かは規定されていませんでした。Javaと C++11 では-3/2常に です-1が、C++03コンパイラはプラットフォームに応じて または を返す可能性があります。C99-1は除算をJava および C++11 と同じように定義しています。どちらの言語も (a と b が整数型の場合)すべてのおよび(ゼロ以外)に対してであることを保証します。C ++03バージョンはプロセッサに固有の切り捨てモードを選択できるため、場合によってはより高速になります。-2(a / b) * b + (a % b) == aabb
• Javaでは整数型のサイズは固定されています（例えば、int32ビット整数は、long64ビット整数は）が、C++では整数とポインタのサイズは、与えられた制約内でコンパイラとアプリケーションバイナリインターフェース（ABI）に依存します。そのため、Javaプログラムはプラットフォーム間で一貫した動作を示しますが、C++プログラムは一部のプラットフォームに合わせて調整が必要になる場合があります。ただし、ローカルプラットフォームに適したより自然な整数サイズを使用することで、より高速に実行できる可能性があります。しかし、C/C++にも固定幅のサイズがあります（例えば、int32_t符号付き32ビット整数は、uint64_t符号なし64ビット整数はなど）。

C++とJavaを比較した例はWikibooksに掲載されています。

C++言語は、ISO/IEC JTC1/SC22/WG21委員会によって発行されるISO規格であるISO/IEC 14882で定義されています。C ++は通常3年周期でリリースされます。^{[ 46 ]}

C++言語は、C++標準委員会と呼ばれる公開運営委員会を通じて進化しています。この委員会は、C++の生みの親であるビャーネ・ストロヴストルップ氏、議長を務めるハーブ・サッター氏、そして業界やユーザーグループの代表者（つまり利害関係者）を含む多くの著名人で構成されています。公開委員会であるため、誰でも自由に参加し、標準規格や技術仕様の今後のリリースに関する提案を行うことができます。委員会は現在、数年ごとに新しい標準規格をリリースすることを目指していますが、過去には厳格な審査プロセスと議論のため、新しい標準規格の公開間隔が長くなった時期もありました（1998年、2003年、2011年）。

Java言語は、Oracle社が発行する書籍であるJava言語仕様書[47]によって定義されています。Javaは通常、^{半年に一度}のサイクルでリリースされますが、従来は2年に一度リリースされていました^{[ 48 ] [ 49 ]。}

Java言語は、 Javaコミュニティプロセスと呼ばれるプロセスを通じて継続的に進化しており、世界のプログラミングコミュニティは、Javaコミュニティメンバー^{[ 50 ]}と呼ばれる人々や組織のグループによって代表されています。このグループは、Java仕様要求と呼ばれる公開要求を送信することで、言語の強化に積極的に取り組んでおり、これらの要求は言語に統合される前に、正式な公開レビューに合格する必要があります。

Javaには確固たる標準規格が存在しないこと、そしてその仕様がやや不安定な性質を持っていることが、新たな言語機能やライブラリ機能の追加において、より安定性と保守性を求める関係者から常に批判の的となっている。対照的に、C++委員会は正反対の理由、すなわち厳格すぎ保守的すぎること、そして新バージョンのリリースに時間がかかりすぎることから、常に批判を受けている。

「C++」は、いかなる企業や組織の商標でもなく、いかなる個人によっても所有されていません。^{[ 51 ]} 「Java」はOracle の商標です。^{[ 52 ]}

• ブロッホ、ジョシュア（2018）。『効果的なJava：プログラミング言語ガイド』（第3 版）。アディソン・ウェスリー。ISBN 978-0134685991。
• Goetz, Brian; Peierls, Tim; Bloch, Joshua; Bowbeer, Joseph; Holmes, David; Lea, Doug (2006). Java Concurrency in Practice . Addison Wesley. ISBN 0-321-34960-1。