Чому C ++ 11 не підтримує призначені списки ініціалізаторів як C99? [зачинено]

Поміркуйте:

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

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

Код, наведений вище, є законним у C99, але не є законним у C ++ 11

Що було c ++ 11 стандартне обґрунтування комітету для виключення підтримки такої зручної функції?

C ++ має конструктори. Якщо є сенс ініціалізувати лише одного члена, то це можна виразити в програмі, застосувавши відповідний конструктор. Цей вид абстракції C ++ сприяє.

З іншого боку, функція призначеного ініціалізатора стосується більше відкриття та полегшення доступу членів безпосередньо до клієнтського коду. Це призводить до таких речей, як наявність людини у віці 18 (років?), Але з ростом і вагою до нуля.

Іншими словами, призначені ініціалізатори підтримують стиль програмування, де виставлені внутрішні елементи, і клієнту надається гнучкість у вирішенні способу використання типу.

C ++ більше зацікавлений у тому, щоб надати гнучкість на стороні дизайнера типу, тому дизайнери можуть полегшити правильне використання типу та складно використовувати неправильно. Покладання дизайнера на контроль того, як можна ініціалізувати тип, є частиною цього: конструктор визначає конструктори, ініціалізатори в класі тощо.

15 липня '17 P0329R4 було прийнято до складуc ++ 20стандарт: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf
Це забезпечує обмежену підтримкуc99призначені ініціалізатори. Це обмеження описано у розділі C.1.7 [diff.decl] .4, якщо:

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

Наступні призначені ініціалізації, які діють на C, обмежені в C ++:

• struct A a = { .y = 1, .x = 2 } недійсний у C ++, тому що позначки повинні відображатися в порядку декларування членів даних
• int arr[3] = { [1] = 5 } недійсний у C ++, оскільки ініціалізація, визначена масивом, не підтримується
• struct B b = {.a.x = 0} недійсний у C ++, тому що конструктори не можуть бути вкладені
• struct A c = {.x = 1, 2} недійсний у C ++, тому що або всі, або жоден із членів даних повинен бути ініціалізований позначеннями

Для c ++ 17і раніше Boost насправді має підтримку призначених Intializer, і було багато пропозицій щодо підтримки підтримкиc ++стандарт, наприклад: n4172 та пропозиція Дарила Уокера про додавання позначення до ініціалізаторів . Пропозиції цитують виконанняc99Позначені ініціалізатори у Visual C ++, gcc та Clang, які заявляють:

Ми вважаємо, що зміни можна буде відносно просто здійснити

Але стандартний комітет неодноразово відхиляє такі пропозиції , заявляючи:

EWG знайшла різні проблеми із запропонованим підходом, і не вважає, що це можливо намагатися вирішити проблему, оскільки це було перепробовано багато разів і кожен раз, коли воно не вдалося

Коментарі Бена Войта допомогли мені побачити непереборні проблеми з таким підходом; дано:

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

У якому порядку будуть закликатися ці функції c99: struct X foo = {.a = (char)f(), .b = g(), .c = h()}? Дивно, але вc99:

Порядок оцінки підекспресій у будь-якому ініціалізаторі невизначено послідовно ^{[ 1 ]}

( Здається, Visual C ++, gcc та Clang мають згоду на поведінку, оскільки всі вони здійснюватимуть дзвінки в цьому порядку :)

Але невизначений характер стандарту означає, що якби ці функції мали будь-яку взаємодію, то стан програми також був би невизначений, і компілятор не попередив би вас : Чи є спосіб попередити про неправильне поведінку призначених ініціалізаторів?

c ++ дійсно має жорсткі вимоги до ініціалізатор-лист 11.6.4 [dcl.init.list] 4:

У списку ініціалізатора списку, встановленого braced-init, засади ініціалізатора, включаючи будь-які, що є результатом розширення пакету (17.5.3), оцінюються в тому порядку, в якому вони з'являються. Тобто, кожне обчислення значення та побічний ефект, пов'язаний із заданим ініціалізаційним пунктом, секвенується перед кожним обчисленням значення та побічним ефектом, пов’язаним із будь-яким ініціалізаторним застереженням, яке слідує за ним у списку відокремлених комами списку ініціалізатора.

Так c ++ підтримка вимагала б, щоб це було виконано в порядку:

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

Порушення сумісності з попередніми c99реалізації.
Як було обговорено вище, цю проблему обійшли обмеження щодо прийнятих у визначені ініціалізаториc ++ 20. Вони забезпечують стандартизовану поведінку, гарантуючи порядок виконання призначених ініціалізаторів.

Трохи хакерства, тож просто ділитися для розваги.

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

І використовувати його так:

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

який розширюється до:

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

Зазначений ініціалізатор наразі включений до складу роботи C ++ 20: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf, щоб ми їх нарешті побачили!

Дві основні особливості C99, у яких C ++ 11 відсутнє, згадується "призначені ініціалізатори та C ++".

Я думаю, що "призначений ініціалізатор" пов'язаний з потенційною оптимізацією. Тут я використовую “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();
}

Ми знали, що час компіляції a_point.xдорівнює нулю, тому можна було очікувати, що fooце оптимізовано в єдиний 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оптимізовано x == 0лише для друку .

Для версії 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();
}

І це вихід оптимізованого коду збирання.

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   

Ми можемо бачити, що a_pointце насправді не постійне значення часу компіляції.