Dlaczego C ++ 11 nie obsługuje wyznaczonych list inicjalizujących jako C99? [Zamknięte]

Rozważać:

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

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

Powyższy kod jest legalny w C99, ale niedozwolony w C ++ 11.

Co to było c ++ 11 uzasadnienie komisji standaryzacyjnej, aby wykluczyć wsparcie dla tak przydatnej funkcji?

C ++ ma konstruktory. Jeśli ma sens zainicjowanie tylko jednego elementu członkowskiego, można to wyrazić w programie za pomocą odpowiedniego konstruktora. To rodzaj abstrakcji promowanej przez C ++.

Z drugiej strony wyznaczona funkcja inicjatorów polega bardziej na ujawnianiu i ułatwianiu dostępu do członków bezpośrednio w kodzie klienta. Prowadzi to do takich rzeczy, jak posiadanie osoby w wieku 18 (lat?), Ale o zerowym wzroście i wadze.

Innymi słowy, wyznaczone inicjatory obsługują styl programowania, w którym elementy wewnętrzne są ujawniane, a klient ma elastyczność w decydowaniu, w jaki sposób chce używać tego typu.

C ++ jest bardziej zainteresowany umieszczeniem elastyczności po stronie projektanta typu, więc projektanci mogą ułatwić prawidłowe użycie typu i utrudnić jego niepoprawne użycie. Zapewnienie projektantowi kontroli nad sposobem inicjalizacji typu jest częścią tego: projektant określa konstruktory, inicjatory w klasie itp.

15 lipca 2017 P0329R4 został przyjęty doc ++ 20standard: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Zapewnia to ograniczone wsparcie dlac99Wyznaczone inicjatory. To ograniczenie opisano poniżej w C.1.7 [diff.decl] .4, biorąc pod uwagę:

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

Następujące wyznaczone inicjalizacje, które są ważne w języku C, są ograniczone w języku C ++:

• struct A a = { .y = 1, .x = 2 } jest nieprawidłowy w C ++, ponieważ desygnatory muszą występować w kolejności deklaracji członków danych
• int arr[3] = { [1] = 5 } jest nieprawidłowy w C ++, ponieważ inicjalizacja wyznaczona przez tablicę nie jest obsługiwana
• struct B b = {.a.x = 0} jest nieprawidłowy w C ++, ponieważ desygnatory nie mogą być zagnieżdżane
• struct A c = {.x = 1, 2} jest nieprawidłowy w C ++, ponieważ wszystkie lub żadne elementy członkowskie danych nie muszą być inicjowane przez desygnatory

Dla c ++ 17a wcześniej Boost faktycznie obsługuje Desygnowanych Intializatorów i było wiele propozycji dodania obsługic ++standard, na przykład: n4172 i propozycja Daryle Walkera, aby dodać oznaczenie do inicjatorów . Propozycje dotyczą implementacjic99Wyznaczone inicjatory w Visual C ++, gcc i Clang:

Uważamy, że zmiany będą stosunkowo łatwe do wdrożenia

Ale komisja standaryzacyjna wielokrotnie odrzuca takie propozycje , stwierdzając:

EWG znalazł różne problemy z proponowanym podejściem i nie sądził, że jest to wykonalne, aby spróbować rozwiązać problem, ponieważ było to wielokrotnie próbowane i za każdym razem kończyło się niepowodzeniem

Komentarze Bena Voigta pomogły mi dostrzec nie do przezwyciężenia problemy związane z tym podejściem; dany:

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

W jakiej kolejności byłyby wywoływane te funkcje c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()}? Co zaskakujące, wc99:

Kolejność oceny podwyrażeń w dowolnym inicjatorze jest nieokreślona ^{[ 1 ]}

( Wygląda na to, że Visual C ++, gcc i Clang mają uzgodnione zachowanie, ponieważ wszystkie będą wykonywać wywołania w tej kolejności :)

Ale nieokreślony charakter standardu oznacza, że ​​gdyby te funkcje miały jakąkolwiek interakcję, wynikowy stan programu również byłby nieokreślony, a kompilator nie ostrzegłby cię : Czy istnieje sposób, aby ostrzec o niewłaściwym działaniu wyznaczonych inicjatorów?

c ++ nie mają rygorystyczne wymogi inicjalizator-List 11.6.4 [dcl.init.list] 4:

W ramach listy inicjalizacyjnej listy inicjalizacyjnej, klauzule inicjalizujące, w tym wszystkie wynikające z rozszerzeń pakietów (17.5.3), są oceniane w kolejności, w jakiej się pojawiają. Oznacza to, że każde obliczenie wartości i efekt uboczny skojarzony z daną klauzulą ​​inicjalizatora jest sekwencjonowany przed każdym obliczeniem wartości i efektem ubocznym związanym z każdą klauzulą ​​inicjalizatora, która następuje po niej, na liście rozdzielanej przecinkami listy inicjalizatora.

Więc c ++ wsparcie wymagałoby wykonania tego w kolejności:

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

Łamanie kompatybilności z poprzednimi wersjami c99wdrożenia.
Jak omówiono powyżej, omijano ten problem przez ograniczenia dotyczące wyznaczonych inicjatorów zaakceptowanych w programiec ++ 20. Zapewniają ustandaryzowane zachowanie, gwarantując kolejność wykonywania Wyznaczonych inicjatorów.

Trochę włamań, więc po prostu udostępniaj dla zabawy.

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

I używaj go jak:

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

który rozszerza się do:

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

Wyznaczone inicjatory są obecnie zawarte w pracy C ++ 20: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf, więc być może w końcu je zobaczymy!

Dwie podstawowe funkcje C99, których w C ++ 11 brakuje, wymienia „Wyznaczone inicjatory i C ++”.

Myślę, że „wyznaczony inicjator” związany jest z potencjalną optymalizacją. Tutaj jako przykładu używam „gcc / g ++” 5.1.

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

Wiedzieliśmy w czasie kompilacji, że a_point.xwynosi zero, więc mogliśmy się spodziewać, że foozostanie zoptymalizowany do jednego 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"

foojest zoptymalizowany x == 0tylko do drukowania .

W przypadku wersji 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();
}

I to jest wyjście zoptymalizowanego kodu asemblera.

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   

Widzimy, że a_pointtak naprawdę nie jest to stała czasowa kompilacji.