Perché C ++ 11 non supporta elenchi di inizializzatori designati come C99? [chiuso]

Tener conto di:

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

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

Il codice sopra è legale in C99, ma non legale in C ++ 11.

Che cos 'era il c ++ 11 la logica del comitato standard per escludere il supporto per una funzione così utile?

C ++ ha costruttori. Se ha senso inizializzare un solo membro, questo può essere espresso nel programma implementando un costruttore appropriato. Questo è il tipo di astrazione che C ++ promuove.

D'altra parte, la funzionalità degli inizializzatori designati riguarda maggiormente l'esposizione e il facile accesso ai membri direttamente nel codice client. Questo porta a cose come avere una persona di 18 anni (anni?) Ma con altezza e peso pari a zero.

In altre parole, gli inizializzatori designati supportano uno stile di programmazione in cui gli interni sono esposti e al client viene data la flessibilità di decidere come desidera utilizzare il tipo.

Il C ++ è invece più interessato a mettere la flessibilità dalla parte del designer di un tipo, quindi i designer possono rendere facile usare un tipo correttamente e difficile da usare in modo errato. Dare al designer il controllo su come un tipo può essere inizializzato è parte di questo: il designer determina i costruttori, gli inizializzatori in classe, ecc.

Il 15 luglio 17 P0329R4 è stato accettato nelc ++ 20standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Questo porta un supporto limitato perc99Inizializzatori designati di. Questa limitazione è descritta come segue da C.1.7 [diff.decl] .4, dato:

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

Le seguenti inizializzazioni designate, valide in C, sono limitate in C ++:

• struct A a = { .y = 1, .x = 2 } non è valido in C ++ perché i designatori devono apparire nell'ordine di dichiarazione dei membri dati
• int arr[3] = { [1] = 5 } non è valido in C ++ perché l'inizializzazione designata dall'array non è supportata
• struct B b = {.a.x = 0} non è valido in C ++ perché i designatori non possono essere annidati
• struct A c = {.x = 1, 2} non è valido in C ++ perché tutti o nessuno dei membri di dati deve essere inizializzato dai designatori

Per c ++ 17 e in precedenza Boost lo ha effettivamente versioni supportano inizializzatori designati e sono state presentate numerose proposte per aggiungere supporto aC ++standard, ad esempio: n4172 e la proposta di Daryle Walker di aggiungere una designazione agli inizializzatori . Le proposte citano l'attuazione dic99Gli inizializzatori designati di Visual C ++, gcc e Clang affermano:

Riteniamo che le modifiche saranno relativamente semplici da implementare

Ma il comitato standard respinge ripetutamente tali proposte , affermando:

EWG ha riscontrato vari problemi con l'approccio proposto e non ha ritenuto fattibile provare a risolvere il problema, poiché è stato provato molte volte e ogni volta ha fallito

I commenti di Ben Voigt mi hanno aiutato a vedere i problemi insormontabili con questo approccio; dato:

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

In quale ordine dovrebbero essere chiamate queste funzioni c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()} ? Sorprendentemente, inc99:

L'ordine di valutazione delle sottoespressioni in qualsiasi inizializzatore è in sequenza indeterminata ^{[ 1 ]}

(Visual C ++, gcc e Clang sembrano avere un comportamento concordato in quanto effettueranno tutte le chiamate in questo ordine :)

Ma la natura indeterminata dello standard significa che se queste funzioni avessero un'interazione, anche lo stato del programma risultante sarebbe indeterminato e il compilatore non ti avviserebbe : c'è un modo per essere avvisati del comportamento anomalo degli inizializzatori designati?

C ++ non hanno requisiti rigorosi di inizializzazione-list 11.6.4 [dcl.init.list] 4:

All'interno della lista di inizializzatori di una lista di inizializzazione con parentesi graffe, le clausole di inizializzazione, comprese quelle risultanti dalle espansioni di pacchetto (17.5.3), vengono valutate nell'ordine in cui appaiono. Cioè, ogni calcolo di valore ed e ff etto laterale associato a una data clausola di inizializzazione viene sequenziato prima di ogni calcolo di valore ed effetto collaterale associato a qualsiasi clausola di inizializzazione che lo segue nell'elenco separato da virgole dell'elenco di inizializzatori.

Così C ++ il supporto avrebbe richiesto che fosse eseguito nell'ordine:

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

Rompere la compatibilità con il precedente c99 implementazioni.
Come discusso in precedenza, questo problema è stato aggirato dalle limitazioni sugli inizializzatori designati accettatic ++ 20. Forniscono un comportamento standardizzato, garantendo l'ordine di esecuzione degli inizializzatori designati.

Un po 'di hackery, quindi condividi solo per divertimento.

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

E usalo come:

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

che si espande a:

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

Gli inizializzatori designati sono attualmente inclusi nel corpo di lavoro di C ++ 20: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf così potremmo finalmente vederli!

Due caratteristiche principali di C99 che mancano a C ++ 11 menzionano "inizializzatori designati e C ++".

Penso che l '"inizializzatore designato" sia correlato alla potenziale ottimizzazione. Qui uso "gcc / g ++" 5.1 come esempio.

#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();
}

Sapevamo al momento della compilazione, a_point.xè zero, quindi potevamo aspettarci che foofosse ottimizzato in un unico 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"

fooè ottimizzato per la x == 0sola stampa .

Per la versione 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();
}

E questo è l'output del codice di assemblaggio ottimizzato.

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   

Possiamo vedere che a_pointnon è realmente un valore di costante del tempo di compilazione.