Bearbeiten. Während das, was ich in meiner ersten Antwort sage, gültig ist, ist dies der wahre Grund:
Am Anfang war C. C ist nicht objektorientiert (Sie können einen OO-Ansatz wählen, aber es hilft Ihnen nicht oder erzwingt nichts).
Dann gab es C With Classes, das später in C ++ umbenannt wurde. C ++ ist objektorientiert und fördert daher die Kapselung und stellt die Invariante eines Objekts sicher. Bei der Erstellung sowie zu Beginn und am Ende einer Methode befindet sich das Objekt in einem gültigen Zustand.
Damit können Sie natürlich erzwingen, dass eine Klasse immer einen Konstruktor haben muss, um sicherzustellen, dass sie in einem gültigen Zustand startet. Wenn der Konstruktor nichts tun muss, um dies sicherzustellen, dokumentiert der leere Konstruktor diese Tatsache .
Ein Ziel mit C ++ war es jedoch, mit C so kompatibel zu sein, dass so weit wie möglich alle gültigen C-Programme auch gültige C ++ - Programme waren (kein so aktives Ziel mehr, und die Entwicklung von C getrennt von C ++ bedeutet, dass es nicht mehr gilt ).
Ein Effekt davon war die Verdoppelung der Funktionalität zwischen structund class. Die ersteren machen die Dinge auf die C-Art (standardmäßig alles öffentlich) und die letzteren machen die Dinge auf eine gute OO-Art (standardmäßig alles privat, der Entwickler macht aktiv öffentlich, was sie öffentlich wollen).
Eine andere ist, dass, damit ein C struct, das keinen Konstruktor haben konnte, weil C keine Konstruktoren hat, in C ++ gültig sein musste, dies eine Bedeutung für die C ++ - Sichtweise haben musste. Obwohl es keinen Konstruktor gibt, der gegen die OO-Praxis verstößt, eine Invariante aktiv sicherzustellen, bedeutet C ++, dass es einen standardmäßigen parameterlosen Konstruktor gibt, der sich so verhält, als hätte er einen leeren Körper.
Alle C structswaren jetzt gültige C ++ structs(was bedeutete, dass sie mit C ++ identisch waren, classeswobei alles - Mitglieder und Vererbung - öffentlich) von außen so behandelt wurde, als hätte es einen einzigen, parameterlosen Konstruktor.
Wenn Sie jedoch einen Konstruktor in ein classoder structeingefügt haben, haben Sie die Dinge eher auf C ++ / OO-Weise als auf C-Weise ausgeführt, und es war kein Standardkonstruktor erforderlich.
Da es als Abkürzung diente, wurde es weiterhin verwendet, auch wenn die Kompatibilität sonst nicht möglich war (es wurden andere C ++ - Funktionen verwendet, die nicht in C enthalten waren).
Als Java (in vielerlei Hinsicht auf C ++ basierend) und später C # (auf unterschiedliche Weise auf C ++ und Java basierend) auf den Markt kamen, behielten sie diesen Ansatz bei, wie es Codierer möglicherweise bereits gewohnt sind.
Stroustrup schreibt darüber in seiner Programmiersprache The C ++ und noch mehr, wobei er sich mehr auf das "Warum" der Sprache in The Design and Evolution of C ++ konzentriert .
=== Ursprüngliche Antwort ===
Nehmen wir an, das ist nicht passiert.
Angenommen, ich möchte keinen parameterlosen Konstruktor, weil ich meine Klasse ohne einen nicht in einen sinnvollen Zustand versetzen kann. In der Tat kann dies structin C # passieren (aber wenn Sie in C # keine Nullen und Nullen sinnvoll verwenden können, verwenden structSie bestenfalls eine nicht öffentlich sichtbare Optimierung und haben ansonsten eine Konstruktionsfehler bei der Verwendung struct).
Damit meine Klasse ihre Invarianten schützen kann, benötige ich ein spezielles removeDefaultConstructorSchlüsselwort. Zumindest müsste ich einen privaten parameterlosen Konstruktor erstellen, um sicherzustellen, dass kein aufrufender Code die Standardeinstellung aufruft.
Was die Sprache noch komplizierter macht. Besser nicht.
Insgesamt ist es am besten, nicht daran zu denken, einen Konstruktor hinzuzufügen, um den Standard zu entfernen, sondern sich überhaupt keinen Konstruktor als syntaktischen Zucker für das Hinzufügen eines parameterlosen Konstruktors vorzustellen, der nichts tut.