Почему 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 фактически поддерживают назначенные инициализаторы, и было множество предложений по добавлению поддержки для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:

В списке инициализаторов списка инициализаторов в фигурных скобках предложения инициализатора, включая те, которые являются результатом расширения пакета (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самом деле это не постоянная времени компиляции.