Tony Parc a apporté une réponse qui est assez proche de la vérité. Le comité C++, fondamentalement, ne pense pas que cela en valait la peine de faire les syndicats d'une part importante de C++, de même pour le traitement des tableaux comme héritage choses, nous avons dû hériter de C, mais n'avais pas vraiment envie.
Les syndicats ont des problèmes: si nous permettons à des non-POD types dans les syndicats, comment sont-ils construits? Il peut certainement être fait, mais pas nécessairement en toute sécurité, et de toute contrepartie serait de demander au comité des ressources. Et le résultat final serait moins satisfaisant, parce que ce qui est vraiment nécessaire à une saine langue est victime de syndicats, et nu C syndicats ne pourrait jamais être élevé de victimes de syndicats, de façon compatible avec le C (que j'imagine, de toute façon).
Pour des précisions sur les questions techniques: depuis que vous pouvez emballer un POD-composante de l'union dans une struct sans perdre quoi que ce soit, il n'y a pas l'avantage des syndicats comme des bases. Avec POD-seulement les éléments de l'union, il n'y a pas de problème avec l'explicite constructeurs tout simplement l'attribution d'un des composants, ni avec l'aide d'un bitblit (memcpy) pour généré par le compilateur, constructeur de copie (ou de cession).
De telles unions, cependant, ne sont pas utiles, assez pour la peine, sauf pour les conserver existants du code C peut être considéré comme valide en C++. Ces GOUSSES seuls les syndicats sont cassés en C++ parce qu'ils ne parviennent pas à maintenir un invariant essentiel qu'ils possèdent dans C: tout type de données peut être utilisé comme un type de composant.
Pour faire syndicats utile, nous devons permettre à constructable types de membres. Ceci est important car il n'est pas acceptable de simplement attribuer un composant dans un constructeur de corps, soit de l'union elle-même, ou un ancêtre struct: vous ne pouvez pas, par exemple, affecter une chaîne à un non initialisée chaîne de composant.
Il en résulte l'on doit inventer des règles pour l'initialisation de l'union composant avec les mem-initialisers, par exemple:
union X { string a; string b; X(string q) : a(q) {} };
Mais maintenant la question est: quelle est la règle? Normalement, la règle est que vous devez initialiser tous les membres et la base de la classe, si vous ne le faites pas de façon explicite, le constructeur par défaut est utilisé pour le reste, et si un type qui n'est pas explicitement initialisée ne possède pas de constructeur par défaut, c'est une erreur (Exception: copie des constructeurs, la valeur par défaut est le membre constructeur de copie].
Clairement cette règle ne peut pas travailler pour les syndicats: la règle est d'être à la place: si l'union a au moins un non-POD membre, vous devez initialiser explicitement exactement un membre dans un constructeur. Dans ce cas, pas de constructeur par défaut, constructeur de copie, opérateur d'affectation, ou destructeur ne sera généré et si l'un de ces membres sont réellement utilisés, ils doivent être explicitement fournis.
Alors maintenant, la question devient: comment écririez-vous, par exemple, un constructeur de copie? Il est bien sûr tout à fait possible de le faire et obtenir le droit si la conception de votre union la manière, disons, X-Windows événement syndicats sont conçus: avec le discriminant de la balise dans chaque composant, mais vous aurez à utiliser le placement de nouvel opérateur pour le faire, et vous aurez à briser la règle que j'ai écrit ci-dessus qui semblait à première vue être correct!
Ce sujet de constructeur par défaut? Si vous n'avez pas l'un de ceux-ci, vous ne pouvez pas déclarer une variable non initialisée.
Il y a d'autres cas où, vous pouvez déterminer la composante de l'extérieur et de l'utilisation du placement de nouvelles pour gérer une union de l'extérieur, mais ce n'est pas un constructeur de copie. Le fait est, si vous avez des N composants que vous auriez besoin d'N des constructeurs, et le C++ a une fracture de l'idée que les constructeurs utilisent le nom de la classe, qui vous laisse plutôt à court de noms et vous force à utiliser des types fantômes pour permettre la surcharge de choisir le bon constructeur .. et vous ne pouvez pas le faire pour le constructeur de copie depuis sa signature est fixe.
Ok, donc, existe-il des alternatives? Probablement, oui, mais ils ne sont pas si faciles à rêver, et plus difficile à convaincre plus de 100 personnes qu'il valait la peine de penser à une rencontre de trois jours, entassés avec d'autres questions.
Il est dommage que la commission n'a pas appliqué la règle ci-dessus: les syndicats sont obligatoires pour l'alignement des données arbitraires et externes de gestion des composants n'est pas vraiment si difficile de le faire manuellement, et trivial et complètement à l'abri lorsque le code est généré par un algorithme convenable, en d'autres termes, la règle est obligatoire si vous souhaitez utiliser le C++ comme compilateur langue cible et de générer lisible, code portable. De telles unions avec constructable membres ont de nombreuses utilisations, mais le plus important est de représenter la trame de pile d'une fonction contenant des blocs imbriqués: chaque bloc de données locales dans une struct, et chaque struct, union composant, il n'est pas nécessaire pour tous les constructeurs ou tel, le compilateur utilisera le placement de nouvelles. Le syndicat fournit à l'alignement et la taille, et la fonte de libre accès aux composants.
[Et il n'y a pas d'autre manière conforme à obtenir l'alignement à droite!]
Donc la réponse à votre question est: êtes vous poser la mauvaise question. Il n'y a aucun avantage à le POD-seuls les syndicats étant bases, et certainement ils ne peuvent pas être issus des classes, car alors il ne serait pas de Gousses. Pour les rendre utiles, un certain temps est nécessaire pour comprendre pourquoi on devrait suivre le principe utilisé partout ailleurs en C++: bits manquants ne sont pas une erreur, sauf si vous essayez de les utiliser.
