Как комитет по стандартам C ++ проверяет свои дизайнерские идеи?

Проверяет ли комитет по С ++ свои новые спецификации проекта с помощью своего рода компилятора прототипов, прежде чем выпускать новый стандарт? Или они выпускают стандарт, который, по сути, является только теоретическим, пока крупные компиляторы не реализуют его?

c++ language-design standards

— Мэтью Джеймс Бриггс
источник

isocpp.org/std/the-life-of-an-iso-proposal

— Роберт Харви

Boost выступает в качестве прототипа для большого числа улучшений библиотеки. Например, boost::shared_ptr> std::shared_ptr.

— MSalters

Я вроде ожидал простого «они не делают».

— Себб

@MSalters: Boost также выступил в качестве прототипа для значительного числа улучшений основного языка (например, boost.lambda=> C ++ 11 лямбда-выражений).

— Джерри Гроб

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

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

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

Краткий ответ: «Нет, комитет не требует тестирования своих проектов с использованием прототипов». Однако в этом нет особой необходимости, потому что члены комитета являются экспертами в C ++, которые понимают все мелкие детали на уровне, которого не знает подавляющее большинство программистов. Помните, что эти люди - языковые архитекторы, которые являются экспертами по теории языка и проектированию компиляторов.

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

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

— Сообщество
источник

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

— Йорг Миттаг

… В конечном итоге в C ++ 17, что означает, что они будут зрелыми в течение 10 лет в качестве реализации и 20 лет в качестве идеи.

— Йорг Миттаг

Это в основном ложно, я думаю. Новые функции , как правило , требуют к реализации первой. Однажды этого не произошло, мы получили экспорт.

— Исана

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

— R ..

@R .. Я не согласен. C ++ 11 был аномалией, но он включал в себя множество вещей, которые уже существовали (см. Мой комментарий Boost, например). На протяжении большей части жизни C ++ он развивался очень медленно, что является одной из основных претензий, которые многие разработчики имеют по поводу языка.