編集。実際、最初の回答で言ったことは有効ですが、これが本当の理由です。
最初に C がありました。C はオブジェクト指向ではありません (オブジェクト指向のアプローチを取ることはできますが、それは役に立たず、何も強制しません)。
その後、C With Classes があり、後に C++ と改名されました。C++ はオブジェクト指向であるため、カプセル化を促進し、オブジェクトの不変条件 (構築時およびメソッドの開始時と終了時にオブジェクトが有効な状態であること) を保証します。
これを行う自然なことは、クラスが有効な状態で開始することを保証するために常にコンストラクターを持たなければならないことを強制することです - コンストラクターがこれを保証するために何もする必要がない場合、空のコンストラクターはこの事実を文書化します.
しかし、C++ での目標は、可能な限りすべての有効な C プログラムが有効な C++ プログラムでもあるという点まで C と互換性を持つことでした (もはや目標としては積極的ではなく、C が C++ から分離して進化したことは、もはやそれが成り立たないことを意味します)。 )。
この影響の 1 つは、 と の間で機能が重複していることstruct
ですclass
。前者は C のやり方 (デフォルトではすべて公開) を行い、後者は優れた OO の方法 (デフォルトではすべて非公開、開発者は公開したいものを積極的に公開する) で物事を行います。
もう 1 つのstruct
理由は、C にはコンストラクターがないためにコンストラクターを持てなかった C が C++ で有効であるためには、C++ の見方に対してこれに意味がなければならないということです。そのため、コンストラクターを持たないことは不変条件を積極的に確保するという OO の実践に反しますが、C++ はこれを、空の本体があるかのように動作するデフォルトのパラメーターなしのコンストラクターが存在することを意味すると解釈しました。
すべての Cstructs
は有効な C++structs
になりました (つまり、C++ と同じで、classes
メンバーと継承 - パブリックのすべてが含まれます)、パラメーターのない単一のコンストラクターがあるかのように外側から扱われます。
class
ただし、またはにコンストラクターを配置した場合はstruct
、C の方法ではなく C++/OO の方法で処理を行うことになり、既定のコンストラクターは必要ありません。
それは省略形として機能したため、他の方法では互換性が不可能な場合でも、人々はそれを使い続けました (C にはない他の C++ 機能を使用していました)。
したがって、Java (多くの点で C++ に基づく) が登場し、その後 C# (さまざまな点で C++ と Java に基づく) が登場したとき、彼らはこのアプローチを、コーダーが既に慣れているものとして維持しました。
Stroustrup はこれについて彼の The C++ Programming Languageで書いており、 The Design and Evolution of C++ では言語の「理由」にもっと焦点を当てています。
=== 元の回答 ===
これは起こらなかったとしましょう。
パラメーターなしのコンストラクターが必要ないとしましょう。コンストラクターがないとクラスを意味のある状態にすることができないからです。実際、これは C# で発生する可能性があるものですstruct
(ただし、C# ですべてゼロと NULL を意味のある方法で使用できないstruct
場合は、せいぜい非公開の最適化を使用しているだけであり、それ以外の場合は、使用上の設計上の欠陥struct
)。
クラスがその不変条件を保護できるようにするには、特別なremoveDefaultConstructor
キーワードが必要です。少なくとも、呼び出しコードがデフォルトを呼び出さないようにするために、パラメーターなしのプライベート コンストラクターを作成する必要があります。
これにより、言語がさらに複雑になります。やらないほうがいい。
全体として、コンストラクターを追加することをデフォルトを削除するものと考えないでください。何もしないパラメーターなしのコンストラクターを追加するためのシンタックス シュガーとして、コンストラクターをまったく持たないことを考えたほうがよいでしょう。