Почему C ++ не может принять подход D для реализации своей концепции?

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

Я узнал, что язык программирования D 2.0 имеет аналогичную функцию для своего общего программирования. Его решение кажется мне довольно элегантным и простым.

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

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

Спасибо за ваши ответы.

ps Чтобы увидеть некоторые примеры общих возможностей программирования D, пожалуйста, обратитесь к этому: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

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

Добавления в стандартную библиотеку были довольно просты. Многие библиотеки были в Boost в течение долгого времени: было доказано, что они работают.

Однако дополнения к основным понятиям в языке гораздо сложнее экспериментировать, поскольку сначала требуется модифицировать компилятор. Функция C ++ 03 (экспорт шаблонов) была указана без поддержки компилятора ... результат был ужасным. Разработчики интерфейса EDG-компилятора сообщили, что это очень трудоемкая задача (несколько человеко-лет) с очень небольшим выигрышем. Ни один другой компилятор никогда не пытался это реализовать. Это не удобная ситуация.

Функции вроде constexprили static_assertбыли просты (и уже эмулированы библиотеками). Лямбды довольно хорошо поняты и реализованы на множестве других языков, уже были проведены обширные исследования, так что это был в основном вопрос синтаксиса.

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

Почему бы не следовать D? Нельзя сказать, что это не так. Комитет призвал людей переосмыслить с нуля, без крайних сроков, и попытаться включить их в компилятор, чтобы увидеть, как они взаимодействуют с другими функциями языка. В частности, возникает вопрос о разделении концепций и концептуальных карт: должны ли они объединяться в единое целое или нет?

К вашему сведению: в настоящее время существует отделение Clang, посвященное этим экспериментам, во главе с Лариссой Воуфо из Университета Индианы.

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

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

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

Вопрос заключается в том, будет ли такое предложение сделано для следующего стандарта и как оно будет сопоставляться с любыми аналогичными предложениями (например, предложениями, касающимися концепций). Предполагая, что может быть сделано приемлемое предложение, я вполне ожидаю, что что-то похожее на концепции или шаблонные ограничения D превратит его в следующий стандарт просто потому, что у него много желания. Вопрос в том, может ли кто-нибудь выдвинуть предложение, которое является достаточно твердым и «достаточно выпеченным», чтобы быть приемлемым.

Вы имеете в виду шаблонные ограничения D?

Насколько я знаю, концепции C ++ были предложены от имени boost :: concept. Проблема в том, что boost - это библиотека, написанная для C ++ 03. C ++ 11 имеет другие возможности синтаксиса, которые позволяют реализовывать определенные вещи по-другому, что позволяет C ++ 03 (следовательно, само boost может быть переписано с использованием преимуществ нового синтаксиса).

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

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

Вот QA с Хербом Саттером, он говорит о концепциях через 15 минут.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

Если вам это нравится, вот еще один: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Теперь по вашему вопросу. Почему не версия D? Ну зачем его использовать? C ++ - очень сложный и стабильный язык. Каждая функция должна быть выбрана чрезвычайно тщательно, потому что она обычно должна поддерживаться в течение десятилетий. Если вы посмотрите на первый стандарт C ++ и следите за редакциями, то есть некоторые устаревшие функции, но даже они все еще должны поддерживаться. Поэтому имеет смысл разработать концепции, которые на 100% соответствуют C ++.

Что касается того, почему это не было включено в C ++ 0x. Ну, потому что это было огромно. Предложение было длиной в 100 страниц, и его было очень сложно реализовать. Было решено, что этой функции требуется больше времени для ее совершенствования, пока она не будет включена в стандарт.

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