Почему std :: initializer_list не является встроенным языком?

Почему не std::initializer_listвстроен базовый язык?

Мне кажется, что это довольно важная особенность C ++ 11, но у него нет собственного зарезервированного ключевого слова (или чего-то подобного).

Вместо этого initializer_listэто просто класс шаблона из стандартной библиотеки, который имеет специальное неявное сопоставление из нового списка инициализации в фигурных скобках. {...} синтаксиса скобках, который обрабатывается компилятором.

На первый взгляд это решение довольно хакерское .

Так будут ли теперь реализовываться новые дополнения к языку C ++: неявными ролями некоторых классов шаблонов, а не базовым языком?

Пожалуйста, рассмотрите эти примеры:

   widget<int> w = {1,2,3}; //this is how we want to use a class

почему был выбран новый класс:

   widget( std::initializer_list<T> init )

вместо использования чего-то похожего на любую из этих идей:

   widget( T[] init, int length )  // (1)
   widget( T... init )             // (2)
   widget( std::vector<T> init )   // (3)

1. классический массив, вы, вероятно, могли бы добавить constздесь и там
2. три точки уже существуют в языке (var-args, теперь вариативные шаблоны), почему бы не использовать синтаксис повторно (и сделать его встроенным )
3. только существующий контейнер, можно добавить constи&

Все они уже являются частью языка. Я написал всего 3 свои первые идеи, уверен, что есть много других подходов.

Уже были примеры «основных» языковых функций, которые возвращали типы, определенные в stdпространстве имен. typeidвозвращается std::type_infoи (возможно, растягивая точку) sizeofвозвращается std::size_t.

В первом случае вам уже нужно включить стандартный заголовок, чтобы использовать эту функцию так называемого «основного языка».

Теперь для списков инициализаторов случается, что для создания объекта не требуется ключевое слово, синтаксис - контекстно-зависимые фигурные скобки. В остальном это то же самое, что и type_info. Лично я не думаю, что отсутствие ключевого слова делает его «более хакерским». Возможно, это немного более удивительно, но помните, что цель заключалась в том, чтобы разрешить тот же синтаксис в фигурных скобках, который уже был разрешен для агрегатов.

Так что да, вы, вероятно, можете ожидать большего от этого принципа дизайна в будущем:

• если возникнут другие случаи, когда можно ввести новые функции без новых ключевых слов, комитет их рассмотрит.
• если для новых функций требуются сложные типы, то эти типы будут помещены stdвнутрь, а не как встроенные.

Отсюда:

• если новая функция требует сложного типа и может быть введена без новых ключевых слов, тогда вы получите то, что у вас есть здесь, а именно синтаксис "основного языка" без новых ключевых слов и который использует типы библиотеки из std.

Я думаю, что все сводится к тому, что в C ++ нет абсолютного разделения на «основной язык» и стандартные библиотеки. Это разные главы стандарта, но каждая из них ссылается на другую, и так было всегда.

В C ++ 11 есть еще один подход, заключающийся в том, что лямбда-выражения вводят объекты, которые имеют анонимные типы, сгенерированные компилятором. Поскольку у них нет имен, они вообще не находятся в пространстве имен, тем более не в std. Однако это не подходит для списков инициализаторов, потому что вы используете имя типа, когда пишете конструктор, который его принимает.

Комитет по стандартизации C ++, похоже, предпочитает не добавлять новые ключевые слова, вероятно, потому, что это увеличивает риск нарушения существующего кода (устаревший код может использовать это ключевое слово как имя переменной, класса или чего-то еще).

Более того, мне кажется, что определение std::initializer_list как шаблонный контейнер - довольно элегантный выбор: если бы это было ключевое слово, как бы вы получили доступ к его базовому типу? Как бы вы его повторили? Вам также понадобится множество новых операторов, и это просто заставит вас запомнить больше имен и больше ключевых слов, чтобы делать то же самое, что вы можете делать со стандартными контейнерами.

Лечение std::initializer_list контейнера как любого другого дает вам возможность написать общий код, который работает с любым из этих элементов.

ОБНОВИТЬ:

Тогда зачем вводить новый тип вместо использования комбинации существующих? (из комментариев)

Начнем с того, что все остальные контейнеры имеют методы для добавления, удаления и размещения элементов, что нежелательно для коллекции, созданной компилятором. Единственное исключение - std::array<>это массив фиксированного размера в стиле C, который, следовательно, останется единственным разумным кандидатом.

Однако, как Никол Болас правильно указует в комментариях, другой, принципиальное отличие std::initializer_listи все другие стандартные контейнеры ( в том числе std::array<>) в том , что последние из них имеет семантику значений , в то время как std::initializer_listимеет эталонную семантику . Копирование std::initializer_list, например, не будет вызывать копию элементов , которые он содержит.

Более того (опять же, любезно предоставлено Николаем Боласом) наличие специального контейнера для списков инициализации фигурных скобок позволяет перегружать способ, которым пользователь выполняет инициализацию.

В этом нет ничего нового. Например, for (i : some_container)полагается на наличие определенных методов или автономных функций в some_containerклассе. C # даже больше полагается на свои библиотеки .NET. На самом деле, я думаю, что это довольно элегантное решение, потому что вы можете сделать свои классы совместимыми с некоторыми языковыми структурами, не усложняя спецификацию языка.

В этом действительно нет ничего нового, и, как многие отмечали, такая практика была и в C ++, и, например, в C #.

Андрей Александреску упомянул об этом хороший момент: вы можете думать об этом как о части воображаемого «основного» пространства имен, тогда это будет иметь больше смысла.

Таким образом, это на самом деле что - то вроде: core::initializer_list, core::size_t, core::begin(), core::end()и так далее. Это просто досадное совпадение, что stdпространство имен имеет внутри некоторые конструкции ядра.

Он не только может полностью работать в стандартной библиотеке. Включение в стандартную библиотеку не означает, что компилятор не умеет хитрить.

Хотя это может быть не во всех случаях, он может очень хорошо сказать: этот тип хорошо известен или простой тип, давайте проигнорируем initializer_list и просто иметь в памяти образ того, каким должно быть инициализированное значение.

Другими словами , int i {5};может быть эквивалентно int i(5);или int i=5;даже intwrapper iw {5};где intwrapperпростой оберткой класса над междунар с тривиальным конструктор принимаетinitializer_list

Он не является частью основного языка, потому что он может быть полностью реализован в библиотеке, только в строке operator newи operator delete. Какое преимущество было бы в том, чтобы сделать компиляторы более сложными для встраивания?