Як комітет стандартів C ++ перевіряє свої дизайнерські ідеї?

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

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

Наскільки я не знаю, формальної вимоги до "тестування" функції чи її дизайну немає. C ++ також дещо унікальний тим, що немає посилання або "первинної" реалізації (наприклад, Microsoft CLR, Oracle JDK, Zend PHP). Однак члени комітету складаються з багатьох організацій з глибокими знаннями мови та впровадження укладача. Наприклад, якщо ви перейдете за цим попереднім посиланням, ви побачите представників Microsoft та Intel, які обоє мають шановані компілятори C ++. Red Hat та кілька інших компаній, які беруть участь у GCC, також беруть участь.

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

Коротка відповідь - «ні, комітет не вимагає тестування їх конструкцій за допомогою прототипування». Однак в цьому немає великої потреби, оскільки члени комітету - це експерти C ++, які розуміють всі тонкі деталі на рівні, якого переважна більшість програмістів не має. Пам'ятайте, ці люди - архітектори мови, які є експертами з теорії мови та дизайну компіляторів.

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

Вони також, як правило, дуже консервативні, поступово додаючи нові функції, що мають попит в реальному світі, не вказуючи велику кількість нових функцій, які можуть виявитися ризикованими. Насправді останніми роками вони додали нові функції, які існували як власні розширення або бібліотеки з відкритим кодом, які вже працюють у реальному світі. Наприклад, C ++ 11 і C ++ 14 містять частини Boost , які вже перевірені в реальному світі в декількох компіляторах та середовищах виконання. Немає потреби тестувати те, що вже перевірено.