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

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

инструмент А, который я использовал в прошлом, которое помогло с этим, некоторые - SQL Delta. Это покажет Вам различия между двумя базами данных (SQL-сервер / Oracle, которой я верю), и генерируйте все сценарии изменения, необходимые для миграции A-> B. Другая хорошая вещь, которую это делает, показать все различия между содержанием базы данных между производством (или тест) DB и Вашим DB разработки. Начиная со все большего количества конфигурации магазина приложений и состояния, которое крайне важно для их выполнения в таблицах базы данных, это может быть реальная боль для имения сценариев изменения, которые удаляют, добавляют и изменяют надлежащие строки. Delta SQL показывает строки в базе данных точно так же, как они выглядели бы в инструменте Diff - измененными, добавленными, удаленными.

превосходный инструмент. Вот ссылка: http://www.sqldelta.com/

8
задан 10 revs, 7 users 32% 30 April 2012 в 08:13
поделиться

9 ответов

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

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

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

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

Q: Разве этот C ++ 0x не большой функция?

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

Q: Нет концепций о добавлении основных новая выразительная сила языка, и таким образом включить основные новые виды программы или стили программирования?

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

8
ответ дан 5 December 2019 в 06:38
поделиться

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

6
ответ дан 5 December 2019 в 06:38
поделиться

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

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

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

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

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

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

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

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

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

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

4
ответ дан 5 December 2019 в 06:38
поделиться

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

2
ответ дан 5 December 2019 в 06:38
поделиться

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

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

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

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

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

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

1
ответ дан 5 December 2019 в 06:38
поделиться

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

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

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

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

1
ответ дан 5 December 2019 в 06:38
поделиться

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

1
ответ дан 5 December 2019 в 06:38
поделиться

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

1
ответ дан 5 December 2019 в 06:38
поделиться

Мне грустно.

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

1
ответ дан 5 December 2019 в 06:38
поделиться
Другие вопросы по тегам:

Похожие вопросы: