Pourquoi C ++ 11 ne prend-il pas en charge les listes d'initialiseurs désignées comme C99? [fermé]

Considérer:

struct Person
{
    int height;
    int weight;
    int age;
};

int main()
{
    Person p { .age = 18 };
}

Le code ci-dessus est légal en C99, mais pas en C ++ 11.

Quel était le c ++ 11 Pourquoi le comité standard a-t-il exclu la prise en charge d'une fonctionnalité aussi pratique?

C ++ a des constructeurs. S'il est judicieux d'initialiser un seul membre, cela peut être exprimé dans le programme en implémentant un constructeur approprié. C'est le genre d'abstraction que le C ++ favorise.

D'autre part, la fonctionnalité d'initialisation désignée consiste davantage à exposer et à rendre les membres faciles d'accès directement dans le code client. Cela conduit à des choses comme avoir une personne de 18 ans (ans?) Mais avec une taille et un poids de zéro.

En d'autres termes, les initialiseurs désignés prennent en charge un style de programmation dans lequel les éléments internes sont exposés, et le client a la possibilité de décider comment il souhaite utiliser le type.

C ++ est plus intéressé à mettre la flexibilité du côté du concepteur d'un type à la place, afin que les concepteurs puissent faciliter l'utilisation correcte d'un type et difficile à utiliser de manière incorrecte. Mettre le concepteur en contrôle sur la façon dont un type peut être initialisé en fait partie: le concepteur détermine les constructeurs, les initialiseurs en classe, etc.

Le 15 juillet 17, P0329R4 a été accepté dans lec ++ 20standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Cela apporte un support limité pourc99Initialiseurs désignés de. Cette limitation est décrite comme suit par C.1.7 [diff.decl] .4, étant donné:

struct A { int x, y; };
struct B { struct A a; };

Les initialisations désignées suivantes, valides en C, sont limitées en C ++:

• struct A a = { .y = 1, .x = 2 } n'est pas valide en C ++ car les désignateurs doivent apparaître dans l'ordre de déclaration des données membres
• int arr[3] = { [1] = 5 } n'est pas valide en C ++ car l'initialisation désignée par tableau n'est pas prise en charge
• struct B b = {.a.x = 0} n'est pas valide en C ++ car les désignateurs ne peuvent pas être imbriqués
• struct A c = {.x = 1, 2} n'est pas valide en C ++ car tous ou aucun des membres de données doivent être initialisés par des désignateurs

Pour c ++ 17et plus tôt Boost prend en charge les initiateurs désignés et il y a eu de nombreuses propositions pour ajouter un support auc ++standard, par exemple: n4172 et la proposition de Daryle Walker pour ajouter une désignation aux initialiseurs . Les propositions citent la mise en œuvre dec99Les initialiseurs désignés de Visual C ++, gcc et Clang revendiquent:

Nous pensons que les changements seront relativement simples à mettre en œuvre

Mais le comité des normes rejette à plusieurs reprises de telles propositions , déclarant:

L'EWG a trouvé divers problèmes avec l'approche proposée et n'a pas pensé qu'il était possible d'essayer de résoudre le problème, car elle a été essayée à plusieurs reprises et chaque fois qu'elle a échoué

Les commentaires de Ben Voigt m'ont aidé à voir les problèmes insurmontables de cette approche; donné:

struct X {
    int c;
    char a;
    float b;
};

Dans quel ordre ces fonctions seraient-elles appelées c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()}? Étonnamment, dansc99:

L'ordre d'évaluation des sous-expressions dans tout initialiseur est séquencé de manière indéterminée ^{[ 1 ]}

(Visual C ++, gcc et Clang semblent avoir un comportement convenu car ils effectueront tous les appels dans cet ordre :)

Mais la nature indéterminée de la norme signifie que si ces fonctions avaient une interaction, l'état du programme résultant serait également indéterminé, et le compilateur ne vous avertirait pas : y a-t-il un moyen d'être averti du mauvais comportement des initialiseurs désignés?

c ++ n'ont des exigences strictes de liste d'initialiseur 11.6.4 [dcl.init.list] 4:

Dans la liste d'initialisation d'une liste d'initialisation accolée, les clauses d'initialisation, y compris celles qui résultent des extensions de pack (17.5.3), sont évaluées dans l'ordre dans lequel elles apparaissent. Autrement dit, chaque calcul de valeur et effet secondaire associé à une clause d'initialisation donnée est séquencé avant chaque calcul de valeur et effet secondaire associé à toute clause d'initialisation qui le suit dans la liste séparée par des virgules de la liste d'initialisation.

Alors c ++ le support aurait exigé que cela soit exécuté dans l'ordre:

1. f()
2. g()
3. h()

Rupture de la compatibilité avec les précédents c99implémentations.
Comme indiqué ci-dessus, ce problème a été contourné par les limitations sur les initialiseurs désignés acceptés dansc ++ 20. Ils fournissent un comportement standardisé, garantissant l'ordre d'exécution des initialiseurs désignés.

Un peu de piratage, donc juste partager pour le plaisir.

#define with(T, ...)\
    ([&]{ T ${}; __VA_ARGS__; return $; }())

Et utilisez-le comme:

MyFunction(with(Params,
    $.Name = "Foo Bar",
    $.Age  = 18
));

qui s'étend à:

MyFunction(([&] {
 Params ${};
 $.Name = "Foo Bar", $.Age = 18;
 return $;
}()));

Les initialiseurs désignés sont actuellement inclus dans le corpus de travail de C ++ 20: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf afin que nous puissions enfin les voir!

Deux fonctionnalités principales du C99 qui C ++ 11 mentionnent «les initialiseurs désignés et C ++».

Je pense que le «initialiseur désigné» est lié à l'optimisation potentielle. Ici, j'utilise «gcc / g ++» 5.1 comme exemple.

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>    
struct point {
    int x;
    int y;
};
const struct point a_point = {.x = 0, .y = 0};
int foo() {
    if(a_point.x == 0){
        printf("x == 0");
        return 0;
    }else{
        printf("x == 1");
        return 1;
    }
}
int main(int argc, char *argv[])
{
    return foo();
}

Nous savions qu'au moment de la compilation, a_point.xc'est zéro, donc nous pouvions nous attendre à ce qu'il foosoit optimisé en un seul printf.

$ gcc -O3 a.c
$ gdb a.out
(gdb) disassemble foo
Dump of assembler code for function foo:
   0x00000000004004f0 <+0>: sub    $0x8,%rsp
   0x00000000004004f4 <+4>: mov    $0x4005bc,%edi
   0x00000000004004f9 <+9>: xor    %eax,%eax
   0x00000000004004fb <+11>:    callq  0x4003a0 <printf@plt>
   0x0000000000400500 <+16>:    xor    %eax,%eax
   0x0000000000400502 <+18>:    add    $0x8,%rsp
   0x0000000000400506 <+22>:    retq   
End of assembler dump.
(gdb) x /s 0x4005bc
0x4005bc:   "x == 0"

fooest optimisé pour imprimer x == 0uniquement.

Pour la version C ++,

#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
struct point {
    point(int _x,int _y):x(_x),y(_y){}
    int x;
    int y;
};
const struct point a_point(0,0);
int foo() {
    if(a_point.x == 0){
        printf("x == 0");
        return 0;
    }else{
        printf("x == 1");
        return 1;
    }
}
int main(int argc, char *argv[])
{
    return foo();
}

Et ceci est la sortie du code d'assemblage optimisé.

g++ -O3 a.cc
$ gdb a.out
(gdb) disassemble foo
Dump of assembler code for function _Z3foov:
0x00000000004005c0 <+0>:    push   %rbx
0x00000000004005c1 <+1>:    mov    0x200489(%rip),%ebx        # 0x600a50 <_ZL7a_point>
0x00000000004005c7 <+7>:    test   %ebx,%ebx
0x00000000004005c9 <+9>:    je     0x4005e0 <_Z3foov+32>
0x00000000004005cb <+11>:   mov    $0x1,%ebx
0x00000000004005d0 <+16>:   mov    $0x4006a3,%edi
0x00000000004005d5 <+21>:   xor    %eax,%eax
0x00000000004005d7 <+23>:   callq  0x400460 <printf@plt>
0x00000000004005dc <+28>:   mov    %ebx,%eax
0x00000000004005de <+30>:   pop    %rbx
0x00000000004005df <+31>:   retq   
0x00000000004005e0 <+32>:   mov    $0x40069c,%edi
0x00000000004005e5 <+37>:   xor    %eax,%eax
0x00000000004005e7 <+39>:   callq  0x400460 <printf@plt>
0x00000000004005ec <+44>:   mov    %ebx,%eax
0x00000000004005ee <+46>:   pop    %rbx
0x00000000004005ef <+47>:   retq   

Nous pouvons voir que ce a_pointn'est pas vraiment une valeur constante de temps de compilation.