C ++ 0x больше не будет иметь концепций. Мнения? Как это повлияет на вас?

Question

На июльском совещании C ++ 0x во Франкфурте было решено удалить понятия из C ++ 0x. Лично я разочарован, но я предпочел бы иметь реализуемый C ++ 0x, а не C ++ 0x. Они сказали, что будут добавлены позже.

Что вы думаете об этом решении / проблеме? Как это повлияет на тебя?

Answer 1

Лично я не слишком недоволен удалением, поскольку целью концепций было главным образом улучшить сообщения об ошибках времени компиляции, как пишет один из соавторов предложения Concepts Джереми Сик (http://lambda -the-ultimate.org/node/3518#comment-50071):

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

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

РЕДАКТИРОВАТЬ: Херб Саттер также пишет в своем блоге :

В: Разве этот C ++ 0x не один большой? особенность?

A: Нет. Концепции были бы великолепны, но для большинства пользователей наличие или отсутствие понятий не сделает разница в их опыте с C ++ 0x за исключением качества ошибок сообщения.

В: Нет понятия о добавлении основных новая выразительная сила в языке, и поэтому позволяют основные новые виды программы или стили программирования?

A: Не совсем. Концепции почти полностью о получении лучшей ошибки сообщения.

Answer 2

Я с нетерпением ждал их. В основном для лучшего сообщения об ошибках, когда компиляция не удалась. Ничего подобного чтению 1000 строк символов, чтобы выяснить ваши глупые ошибки.

Answer 3

Мне грустно видеть, что они выпадают из списка.

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

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

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

Для меня концепции приносят типы в общее программирование, а интерфейсы определенности приносят в ОО, лучшая компиляция - это просто бонус.

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

Answer 4

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

Answer 5

Мне грустно.

Я проверяю ConceptGCC , и это здорово! Я уже пишу некоторую простую библиотеку, используя это, и вижу некоторые недостатки, такие как больший объем кода для написания или некоторые проблемы с умом, думая о силе абстракции концепций. Библиотека концепций std действительно создает проблемы, поэтому включать ее в стандарт - просто недоразумение. Я думаю, что будущий стандарт должен только стандартизировать грамматику понятия и дать некоторые советы, как его использовать.

Answer 6

Я тоже думал, что это был плохой вызов и что C++0x будет хуже для удаления, но только что закончил читать "Страуструп" Упрощение использования концепций Я передумал. Я понятия не имел, что предложение по концепции было настолько сложным, и я думаю, это хорошо, что оно будет хорошо продумано, прежде чем будет добавлено в язык. Несмотря на то, что Страуструп проповедует сохранение концепций, его статья убедила меня в том, что в нынешнем виде концепции принесут больше вреда, чем пользы, и хотя BS предлагает решение, я боюсь, что оно может быть спешно, и не все последствия еще не поняты.

Answer 7

Это очень грустно. Внедрение концепций в C ++ привело бы к тому, что его система типов приблизилась бы к тому же уровню мощности, что и классы типов Haskell, и это было бы замечательно - язык, оптимизированный для скорости, позволяющий вам делать все, что вы хотите, и в то же время строго безопасный для типов, если вы не используете аварийные отверстия (пока еще остается быстро!). Предполагалось также исправить давнюю проблему сложности использования STL и Boost (и библиотек шаблонов в целом) из-за слабой «утки во время компиляции» природы шаблонов C ++ 03 и связанных с этим проблем с компилятором. сообщение об ошибке.

Answer 8

Я думаю, что они приняли правильное решение. Я бы хотел видеть высококачественную реализацию концепций, добавленных к языку, но спецификация двигалась в неправильном направлении, накладывая слишком большое бремя на пользователя, чтобы явно указывать карты концептов. Бумага Страуструпа действительно предлагает некоторые исправления, но это будет довольно радикальное изменение, так что я думаю, что так поздно в этом процессе. И без компилятора, чтобы проверить его.

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

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

Честно говоря, я рад видеть, что они рисковали и удалили их на данный момент. До сих пор мы жили без концепций, и я могу жить без них еще 5 лет.

Answer 9

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

Я думаю, что это даже мощнее и лучше, чем реализовывать все полезные функции непосредственно в типе и получать к ним доступ через интерфейсы, как в .NET. Это не позволяет расширять позже (хорошо, .NET знает методы расширения начиная с 3.0 (или 3.5, не уверен), но это не то же самое).

Улучшение сообщений об ошибках - еще одно (и оригинальное) большое улучшение, которое приносят концепции.

Но одна из моих первых мыслей, когда я читал о концепциях, была: это займет ОЧЕНЬ много времени, пока GCC и MSVC не поддержат его.

Так что я думаю, что имеет смысл удалить его из будущего стандарта. НО, что я хотел бы, это фиксированное соглашение функций для стандартов после C ++ 0x, которое содержит концепции. Это позволило бы поставщикам компиляторов лучше подготовиться к стандарту C ++ 2x.

Так что я очень надеюсь, что мы увидим концепции в недалеком будущем.