Чому std :: initializer_list не є вбудованою мовою?

Чому не std::initializer_listвбудована основна мова?

Мені здається, що це досить важлива особливість C ++ 11, і все ж він не має власного зарезервованого ключового слова (або чогось іншого).

Натомість initializer_listце просто клас шаблону зі стандартної бібліотеки, який має спеціальне, неявне зіставлення з нового синтаксису дужок-init-list, {...} що обробляється компілятором.

На перший погляд, це рішення є досить хакі .

Чи так тепер будуть реалізовані нові доповнення до мови С ++: неявними ролями деяких класів шаблонів, а не основною мовою?

Будь ласка, розгляньте ці приклади:

   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. Однак це не підходить для списків ініціалізатора, оскільки ви використовуєте ім'я типу, коли пишете конструктор, який приймає такий.

Здається, Стандартний комітет С ++ вважає за краще не додавати нові ключові слова, ймовірно, тому, що це збільшує ризик злому існуючого коду (застарілий код міг використовувати це ключове слово як ім'я змінної, класу чи чогось іншого).

Більше того, мені здається, що визначення std::initializer_listяк шаблонного контейнера є цілком елегантним вибором: якби це було ключове слово, як би ви отримали доступ до його основного типу? Як би ви це повторили? Вам також знадобиться купа нових операторів, і це просто змусить вас запам'ятати більше імен і більше ключових слів, щоб робити те саме, що ви можете робити зі стандартними контейнерами.

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

ОНОВЛЕННЯ:

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

Почнемо з того, що всі інші контейнери мають методи додавання, видалення та заміни елементів, що не бажано для колекції, створеної компілятором. Єдиним винятком є ​​те std::array<>, що обгортає масив у стилі C фіксованого розміру і, отже, залишається єдиним розумним кандидатом.

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

Більше того (ще раз, люб'язно надано Nicol Bolas), наявність спеціального контейнера для списків для ініціалізації фігурних дужок дозволяє перевантажувати спосіб виконання користувачем ініціалізації.

Це нічого нового. Наприклад, 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. Яка перевага була б у тому, щоб ускладнювати компілятори для її вбудовування?