Edit. En fait, tout ce que je dis dans ma première réponse est valide, c'est la vraie raison.:
Au début il y avait C. C n'est pas orienté objet (vous pouvez prendre une approche OO, mais il ne vous aide pas ou imposer quoi que ce soit).
Puis il y a de C Avec des Classes, qui a été renommé plus tard en C++. C++ est orienté objet, et, par conséquent, encourage l'encapsulation, et de s'assurer d'un objet invariant lors de la construction et du début et de la fin de la méthode, l'objet est dans un état valide.
La chose naturelle à faire, est de faire valoir qu'une classe doit toujours avoir un constructeur pour s'assurer qu'il démarre dans un état valide - si le constructeur n'a rien à faire pour s'en assurer, alors le constructeur vide consignera ce fait.
Mais un but avec le C++ est compatible avec C au point que, autant que possible, valide tous les programmes en C, où valide les programmes C++ (qui n'est plus aussi actif un but, et l'évolution de C distinct de C++ signifie qu'il ne tient plus).
L'une des conséquences de ceci est la duplication de fonctionnalités entre struct et class. L'ancien faire des choses comme en C (tout ce qui est public par défaut) et le dernier à faire les choses bien OO façon (tout ce qui est privé par défaut, développeur activement rend public ce qu'ils veulent publique).
Un autre est que, pour un C struct, ce qui ne pouvait pas avoir un constructeur parce que le C n'a pas de constructeurs, pour être valide en C++, puis il y avait un sens pour ce pour le C++ façon de voir les choses. Et donc, bien que n'ayant pas un constructeur irait à l'encontre de l'OO pratique de la veille activement à un invariant, C++ a pris ce à dire qu'il y avait un défaut constructeur sans paramètre qui a agi comme il avait un corps est vide.
Tous les C structs étaient maintenant valide en C++ structs, (ce qui signifiait qu'ils étaient les mêmes qu'en C++ classes avec tout les membres de l'héritage - public) traité de l'extérieur, comme si elle avait un seul constructeur sans paramètre.
Toutefois, si vous avez mis un constructeur dans un class ou struct, alors que vous faisiez les choses le C++/OO façon plutôt que comme en C, et il n'y avait pas besoin d'un constructeur par défaut.
Depuis, il a servi comme une abréviation, les gens de les utiliser même lorsque la compatibilité n'était pas possible de faire autrement (il a utilisé d'autres fonctionnalités C++ en C).
C'est pourquoi, lorsque Java est venu le long de (basé sur le C++ dans de nombreuses façons) et, plus tard, C# (basé sur le C++ et Java de différentes manières), ils ont gardé cette approche comme quelque chose de codeurs peuvent déjà être utilisé.
Stroustrup écrit à ce sujet dans son Le Langage de Programmation C++ et plus encore, avec plus d'accent sur le "pourquoi" de la langue dans La Conception et l'Évolution de C++.
=== Réponse Originale À Cette Question ===
Disons que ce n'est pas arrivé.
Disons que je ne veux pas d'un constructeur sans paramètre, parce que je ne peux pas mettre ma classe significative de l'état sans que l'un. En effet, c'est quelque chose qui peut se produire avec l' struct en C# (mais si vous ne pouvez pas faire une utilisation judicieuse de tous les zéros et les valeurs null struct en C# vous êtes, au mieux, à l'aide d'un non-public-visible de l'optimisation, et ont un défaut de conception à l'aide de struct).
Pour faire de ma classe en mesure de protéger ses invariants, j'ai besoin d'un spécial removeDefaultConstructor mot-clé. Au moins, j'aurais besoin de créer un privé constructeur sans paramètre pour s'assurer qu'aucun code d'appel des appels par défaut.
Ce qui complique la langue un peu plus. Mieux de ne pas le faire.
Dans tous, il est préférable de ne pas penser à ajouter un constructeur que la suppression du défaut, mieux à penser de ne pas avoir de constructeur tout comme sucre syntaxique pour l'ajout d'un constructeur sans paramètre qui ne fait rien.
