L'initialisation d'une union avec un non-trivial constructeur

J'ai une structure qui j'ai créer un constructeur pour initialiser les membres à 0. J'ai vu dans les anciens compilateurs que lorsqu'en mode release, sans en faire un memset à 0, les valeurs ne sont pas initialisés.

Je veux maintenant utiliser cette structure dans une union, mais des erreurs parce que c'est un non-trivial constructeur.

Donc, la question 1. Le compilateur par défaut mis en œuvre constructeur de garantir que tous les membres d'une structure sera initialisé à null? Le non-trivial constructeur a tout simplement un memset de tous les membres de '0' pour assurer la propreté de la structure.

Question 2: Si un constructeur doit être spécifié sur la base de la structure, comment un syndicat soit mis en œuvre pour contenir un élément et d'assurer un 0 initialisé élément de base?

InformationsquelleAutor Superpolock | 2008-11-26
  1. 47

    Question 1: par Défaut, les constructeurs ne initialiser POD membres à 0 selon la norme C++. Voir le texte cité ci-dessous.

    Question 2: Si un constructeur doit être spécifié dans une classe de base, alors que la classe ne peut pas faire partie d'un syndicat.

    Enfin, vous pouvez fournir un constructeur pour votre union:

    union U 
{
   A a;
   B b;

   U() { memset( this, 0, sizeof( U ) ); }
};

    Pour Q1:

    À partir de C++03, 12.1 les Constructeurs, pg 190

    La implicitement par défaut définis par le constructeur effectue l'ensemble des initialisations de l'
    classe qui serait effectuée par un utilisateur écrit dans le constructeur par défaut pour la classe avec un vide mem-initialiseur de liste (12.6.2) et un vide corps de la fonction.

    À partir de C++03, 8.5 Initialiseurs, page 145

    Par défaut-initialiser un objet de type T signifie:

    • si T est un non-POD type de classe
      (article 9), le constructeur par défaut
      pour T est appelé (et le
      l'initialisation est mal formé, si T
      n'a pas accessible par défaut
      le constructeur);
    • si T est de type tableau, chaque élément par défaut est initialisée;
    • sinon, l'objet est initialisé à zéro.

    À zéro-initialiser un objet de type T signifie:

    • si T est un type scalaire (3.9), l'objet est défini à la valeur de 0 (zéro) est converti en T;
    • si T est un non-union type de classe, chaque membre de données statiques et chaque classe de base sous-objet est initialisé à zéro;
    • si T est un type d'union, l'objet premier de données nommée membre est initialisé à zéro;
    • si T est de type tableau, chaque élément est initialisé à zéro;
    • si T est un type de référence, pas d'initialisation est effectuée.

    Pour Le T2:

    À partir de C++03, 12.1 les Constructeurs, pg 190

    Un constructeur est trivial si il est implicitement déclarée de constructeur par défaut, et si:

    • sa classe n'a pas de fonctions virtuelles (10.3) et pas de virtuel classes de base (10.1), et
    • tous les directe les classes de base de sa classe ont trivial constructeurs, et
    • pour tous les non statiques de données des membres de sa classe qui sont de type classe (ou d'une matrice,
      de celui-ci), chaque classe a un trivial constructeur

    À partir de C++03, 9.5 Syndicats, pg 162

    Un syndicat peut avoir les fonctions membres (y compris les constructeurs et destructeurs), mais pas virtuel (10.3) de fonctions. Un syndicat ne peut pas les classes de base. Un syndicat ne peut pas être utilisée comme classe de base.Un objet d'une classe avec un non-trivial constructeur (12.1), un non-trivial constructeur de copie (12.8), un non-trivial destructeur (12.4), ou à un non-trivial copie opérateur d'affectation (13.5.3, 12.8) ne peut pas être membre d'un syndicat, ni un tableau de ces objets

    • Ce qui manque ici, c'est que malgré le nom, par défaut, les constructeurs ne sont pas par défaut d'initialisation-POD membres. 12.6.2/4 dit ce qui se passe lorsqu'un membre n'est pas mentionné dans une liste d'initialiseur, et par votre citation de 12.1, cela s'applique à l'implicite ctors. Il dit, "Si l'entité est un non-membre de données statiques de ... type de classe ... et la classe d'entité est un non-POD classe, l'entité par défaut est initialisée ... dans le cas contraire, l'entité n'est pas initialisé". Ainsi, la GOUSSE de données des membres ne sont pas initialisées par le implicitement générés constructeur. Non-POD membres de données par défaut sont initialisées.
    • cette réponse est de la date..voir ma réponse pour le C++11 ci-dessous
    InformationsquelleAutor David Rodríguez - dribeas
  2. 34

    Les choses ont changé pour le mieux en C++11.

    Vous pouvez maintenant légalement le faire, que décrit par Stroustrup lui-même (j'ai atteint ce lien à partir de la Article de wikipédia sur le C++11).

    L'exemple sur Wikipédia est comme suit:

    #include <new> //Required for placement 'new'.

struct Point {
    Point() {}
    Point(int x, int y): x_(x), y_(y) {}
    int x_, y_;
};

union U {
    int z;
    double w;
    Point p; //Illegal in C++03; legal in C++11.
    U() {new(&p) Point();} //Due to the Point member, a constructor
                           //definition is now *required*.
};

    Stroustrup va dans un peu plus en détail.

    • Techniquement vos conseils un constructeur est requis n'est pas correct. Comme les autres membres, il est seulement nécessaire si elle est utilisée. Stockage brut pourrait être initialisé à un int, double, ou un Point, puis un pointeur vers U pourrait être utilisé pour y accéder (suivi du nom du champ). Exemple les utilisations comprennent l'interprétation d'un flux d'objets, l'émulation d'une pile, ou tout simplement l'interprétation d'une valeur alloué sur le tas.
    • s'il est vrai que vous n'avez pas besoin de définir un constructeur à moins que vous construire une instance de U, je ne crois pas que c'est légal d'utiliser un U * pour accéder à tout membre de l'union, si aucun syndicat de l'objet a été construit. [de base.la vie] Avant la durée de vie d'un objet a commencé, mais après le stockage de l'objet occupera a été attribué [...] un pointeur qui fait référence à l'emplacement de stockage [...] peut être déréférencé, mais [...]. Le programme a un comportement indéfini si [...] le pointeur est utilisé pour accéder à un non-membre de données statiques ou appeler un non-membre statique de la fonction de l'objet
    • ses délicates. Certains les alias permettent de choses que vous ne voudriez pas attendre d'une lecture naïve, esp, compte tenu de la stricte aliasing règles. Le C comité a également fait une erreur en limitant la mise en page de l'ensemble des types, permet de prouver des choses sont valides qui, autrement, ne seraient pas. Si vous combinez ces règles, vous vous retrouvez avec des contradictions dans les normes. Potentiellement juridique alias inclure des nombres entiers et des entiers non signés de la même taille qui partagent une valeur commune, uintptr_t et un pointeur, unsigned char et n'importe quoi, et convenablement grand entier non signé n'importe quel magasin, initialisé ou non.
    • mise en page à elle seule ne permet pas d'aliasing, où il est invalide. À l'aide d'une union pointeur pour accéder à un champ de membre n'est pas seulement l'accès à un membre; l'union de l'objet est également accessible, et c'est ce qui est problématique dans ce cas; si il n'y a pas de constructeur approprié disponible, alors il doit être illégale selon le paragraphe cité ci-dessus.
    • au contraire, quand il n'y a pas de syndicat de l'objet, de l'accès par les membres de l'union de l'opérateur est l'accès via le type d'union, et qui ne peut pas alias arbitrairement avec ses types de membres, au moins selon les développeurs de GCC point de vue et je pense que diverses autres).
    • Je pense que la difficulté est que l'union n'a pas besoin d'un constructeur. Vous pouvez, dans certains cas, memcpy déjà de la valeur construite dans un composant OU si il existe un composant de type X dans l'union U, il peut être construit à l'extérieur. Il n'est pas nécessaire en C++11 qui un constructeur pour U existe pas, à moins que celui-ci est exigé par les usages. Je sais à propos de cette règle car je me suis battu pour en C++89 et a échoué. BTW: les développeurs de GCC a cassé des tas d'précédemment code de travail, et refusé d'autres déjà utilisé des optimisations (mon système avait pour désactiver le strict aliasing).
    • BTW, vous pouvez trouver qu'il est amusant à regarder l'utilisation de C++11 de l'union dans github.com/felix-lang/addrstore/blob/master/node16.hpp qui, je l'espère, est bien défini (compile et s'exécute, mais je ne peux pas être sûr). la nécessité dans cet exemple, c'est en raison de paire (pointeur, iterator) où si le pointeur est NULL, l'itérateur est pas défini. Mais un constructeur est encore nécessaire et je n'en ai pas, donc je dois faire une union de deux structures, l'une avec et l'autre sans l'itérateur, donc je n'ai pas de construire l'itérateur.
    • BTW: il y a des moments où l'échec de la Norme C++ pour assurer le comportement n'est pas pertinent si vous avez d'autres connaissances qui ne l'assurer. Il n'y a pas de définition en C++ de la conformité du programme. Par exemple, j'ai un garbage collector qui examine régulièrement la machine de la pile et non initialisée magasin. Si le compilateur/linker jamais cassé que (ce qui pourrait être en droit d') il vaut mieux qu'ils fournissent un commutateur pour désactiver l'optimisation qui brise ou QOI questions de dire que je vais passer à un autre compilateur.
    • dans certains cas, peuvent memcpy déjà de la valeur construite dans un composant OU si il existe un composant de type X dans l'union U, il peut être construit à l'extérieur", le problème est que vous ne pouvez pas avoir une union de l'objet (et donc de composants) à memcpy si vous ne pouvez pas construire un tel objet. Je sais que dans la pratique ce que vous êtes suggérant fonctionne habituellement très bien (et avec certains compilateurs peuvent être garanti à travailler), mais je pense que c'est techniquement valide, selon une lecture stricte de la norme.
    • Désolé, je suis pas sûr de qui vous voulez dire quand vous dites "si vous ne pouvez pas construire un tel objet". Une union U est une déclaration de type. Il n'est pas nécessaire de tout les constructeurs existent pour l'union, ni pour aucun des types de composant. Vous pouvez définir le type .. en C++11. La seule obligation pour les constructeurs d'exister, c'est si vous essayez d'utiliser effectivement un. Une union sans les constructeurs est parfaitement bonne adresse pour les calculs. [voir la suite]
    • Par exemple, en C++11, vous n'avez pas besoin d'effectuer les opérations suivantes (autres installations), mais vous pouvez déclarer union de tous types pour les fins du calcul de la taille maximale et l'alignement des types. L'union n'est jamais construit. Même les types qui y participent ne peut jamais être construit. En C++, 89, vous n'étiez pas capable de faire cela, et il n'y a pas de fonction pour calculer l'alignement.
    • vous pouvez également noter votre langue "techniquement non valide" est dénué de sens, non-sens (pas de sens à être offensant, mais techniquement précises). En C++, un programme peut avoir la propriété de "mal formé", ce qui signifie que conforme compilateur doit émettre un diagnostic message d'erreur. Cela ne veut pas dire que le programme n'est pas déterministe de la sémantique! Bizarre, mais vrai. Il y a aussi des phrases dans la Norme "XXX est un comportement indéterminé". La plupart des gens n'ont aucune idée de ce que cela signifie. Il signifie absolument rien du tout! [prochaine]
    • En fait "un comportement indéterminé" est écrit comme un contre-vérifier pour le comité des Normes de lui-même. Il n'a pas d'autre but. Là si quelqu'un peut dire "X dit que ce n'est défini et Y dit pas défini, veuillez préciser!". Il existe en effet de nombreux cas où la Norme dit pas défini, mais, en fait, d'autres règles, peut-être, y compris la mise en œuvre des règles définies, en fait, permettent de déduire le comportement. [prochaine]
    • Par exemple, si un unsigned int est de 4 octets, et il a le maximum de valeur 2^32-1, puis le chargement d'une valeur non initialisée de ce type de allouées magasin est bien défini. La valeur chargé peut être pour une période indéterminée, mais une valeur de 0 à 2^32-1, il va nécessairement avoir. Vous pouvez déduire de ce fait. Il a de travailler. Le compilateur ne peut pas rejeter le programme ou ne parviennent pas à effectuer l'opération. [prochaine]
    • Un plus intéressant et utile exemple, peut-être: peu fait tripoter le les bits de poids faible de pointeurs. - Je faire dans mon garbage collector. C'est bien définie (à condition uintptr_t est défini). C'est une pratique courante dans le code bas-niveau.
    • Grosso modo, le ctor/affecter/dtor règles s'appliquent uniquement aux types abstraits sont pas ceux concrète. Et parfois vous pouvez même comprendre des choses sur eux trop. Ceci est aggravé si de nouveaux C99 les règles sont appliquées de C++, qui met très mal les restrictions sur les représentations d'entiers (à cause de l'ignorance des mathématiques de base dans la norme ISO C comité).
    • Je suis en désaccord avec ce que vous dites. À l'aide d'une variable non initialisée est précisément défini et ne peut pas nécessairement générer une valeur, même si un motif de bits de la taille appropriée ne peut que représenter une valeur valide; le programme peut simplement se bloquer immédiatement, ou au contraire de se comporter de façon imprévisible, parce que le compilateur est permis de supposer que vous va pas le faire et de générer du code en conséquence (et est même permis de détecter si vous le faites, et de générer un diagnostic et de mettre fin à l'exécution du programme). UB est défini explicitement dans la norme d'une manière qui permet de faire cela.
    • Je ne pense pas que nous puissions avoir une discussion sérieuse à propos de cette réponse sans avoir un accord sur les conséquences de l'exécution de code qui appelle spécifiquement à un comportement indéterminé, et de toute façon ce n'est pas vraiment destiné à être un forum pour la large discussion, nous allons donc en accord ou en désaccord.
    • Oui, le compilateur peut supposer que si elle dispose de suffisamment d'information. Mais il ne peut pas. Ma GC, et le compilateur ne peut pas savoir parce qu'il est compilé séparément. Vous aussi vous manquez le point indéfini, n'a pas de sens. D'autres règles peuvent spécifier le comportement dans un endroit qui n'est pas défini dans un autre. Je sais comment la conformité à un modèle qui fonctionne. J'y étais 🙂

    InformationsquelleAutor dan-man
  3. 3

    Autant que je sache, les membres du syndicat peuvent ne pas avoir les constructeurs ou destructeurs.

    Question 1: non, il n'y a pas de garantie. Toute POD-membres qui ne sont pas dans la liste d'initialisation du constructeur obtient par défaut-initialisé, mais c'est avec un constructeur que vous définissez, et a une liste d'initialiseur. Si vous ne définissez pas un constructeur, ou vous pouvez définir un constructeur sans un initialiseur liste et le corps est vide, POD-membres ne sera pas initialisé.

    Non-POD membres seront toujours construits par l'intermédiaire de leur constructeur par défaut, qui, si synthétisé, encore une fois ne serait pas initialiser POD-membres. Étant donné que les membres du syndicat peuvent ne pas avoir les constructeurs, vous serais assez bien être garanti que POD-membres de structs dans une union ne sera pas initialisé.

    Question 2: vous pouvez toujours initialiser les structures et les syndicats de la sorte:

    struct foo
{
    int a;
    int b;
};

union bar
{
    int a;
    foo f;
};

bar b = { 0 };
    • Vous pouvez donner à l'union elle-même un constructeur qui memset de lui-même à zéro.
    • Bon point! J'oublie à propos de l'union des constructeurs de moi-même!
    • Il n'y a pas de différence entre l'un des programmeurs de constructeur par défaut sans liste d'initialiseur et le corps est vide et un compilateur a généré constructeur.
    • merci, je ne l'ai pas écrit très clairement, et mis à jour ma réponse en conséquence.
    • Une différence est que l'ancien rend la classe non-POD, tandis que le second ne l'est pas.
    InformationsquelleAutor
  4. 2

    Comme mentionné dans Greg Rogers commentaire à unwesenaprès, vous pouvez donner à votre union un constructeur (et destructeur si vous le souhaitez):

    struct foo
{
    int a;
    int b;
};

union bar
{
    bar() { memset(this, 0, sizeof(*this)); }

    int a;
    foo f;
};
    • Semble que j'ai besoin d'une certaine éducation. Ne serait pas memsetting l'objet à zéro, effacer les classes virtuelles table?
    • Deux choses, 1) vous n'avez pas à utiliser une vtable pour mettre en œuvre le polymorphisme (à l'exception de tout le monde). 2) voyez-vous des méthodes virtuelles sur foo? Ou tout du tout les méthodes pour que la matière?. Est-il hériter de quoi que ce soit? Il n'y a pas vtable sans méthodes virtuelles. En fait, ont été foo pour les méthodes virtuelles et, par extension, une vtable, il ne serait plus un POD, et donc inéligible pour l'adhésion dans l'union.
    InformationsquelleAutor Adam Rosenfield
  5. 0

    Pouvez-vous faire quelque chose comme cela?

    class Outer
{
public:
    Outer()
    {
        memset(&inner_, 0, sizeof(inner_));
    }
private:
    union Inner
    {
        int qty_;
        double price_;
    } inner_;
};

    ...ou peut-être quelque chose comme cela?

    union MyUnion
{
    int qty_;
    double price_;
};

void someFunction()
{
    MyUnion u = {0};
}
    • Nous l'avions considéré que, mais la structure, nous avons tenté de mettre dans l'union est en cours d'utilisation dans d'autres parties du code, afin de retirer le constructeur(en supposant que le compilateur traite de la structure que de la GOUSSE et de ne pas initialiser tous les éléments à 0) pourrait bloquer le code qui en dépend.
    InformationsquelleAutor John Dibling
  6. -1

    Vous aurez à attendre pour C++0x pour être pris en charge par les compilateurs de l'obtenir. Jusqu'alors, désolé.

    InformationsquelleAutor Michel