Почему концепции (generic programming) были задуманы, когда у нас уже были классы и интерфейсы?
Также на programers.stackexchange.com:
Я понимаю, что концепции STL должны существовать, и было бы глупо называть их "классами" или "интерфейсами", когда на самом деле они являются только документально подтвержденными (человеческими) концепциями и не могут быть переведены на код С++ на время, но когда им предоставляется возможность расширить язык для размещения концепций, почему они просто не изменяли возможности классов и/или вводили интерфейсы?
Разве это не очень похоже на интерфейс (100% абстрактный класс без данных)? Посмотрев на это, мне кажется, что интерфейсов не хватает поддержки аксиом, но, возможно, аксиомы могут быть введены в интерфейсы С++ (учитывая гипотетическое принятие интерфейсов на С++ для принятия концепций), не могли ли они? Я думаю, что даже автоматические концепции могут быть легко добавлены в такой интерфейс С++ (автоматический интерфейс LessThanComparable, любой?).
Не является ли понятие concept_map очень похожим на шаблон адаптера? Если все методы являются встроенными, адаптер по существу не существует вне времени компиляции; компилятор просто заменяет вызовы на интерфейс с помощью встроенных версий, вызывая целевой объект непосредственно во время выполнения.
Я слышал о том, что называется статическим объектно-ориентированным программированием, что по сути означает эффективное повторное использование концепций объектной ориентации в общем программировании, что позволяет использовать большую часть мощности ООП без накладных расходов на выполнение. Почему еще не рассматривалась эта идея?
Надеюсь, это достаточно ясно. Я могу переписать это, если вы думаете, что я не был; просто дайте мне знать.
Ответы
Ответ 1
Существует большая разница между ООП и общим программированием, предопределением.
В OOP, когда вы создаете класс, у вас были интерфейсы, которые, по вашему мнению, будут полезны. И это было сделано.
В общем программировании, с другой стороны, если класс соответствует заданному набору требований (главным образом методам, но также и внутренним константам или типам), то он подходит к счету и может использоваться. Предложение Концепции заключается в его формализации, так что обнаружение может происходить непосредственно при проверке сигнатуры метода, а не при создании экземпляра тела метода. Это также упрощает проверку шаблонов, поскольку некоторые методы могут быть отклонены без каких-либо инстанцирования, если понятия не совпадают.
Преимущество Concepts заключается в том, что вы не страдаете от Predestination, вы можете выбрать класс из Library1, выбрать метод из Library2, и если он подходит, вы являетесь золотым (если это не так, вы можете используйте концептуальную карту). В OO вы должны каждый раз писать полноценный адаптер.
Вы правы, что оба кажутся похожими. Разница в основном связана с временем привязки (и тем, что Concept по-прежнему имеет статическую диспетчеризацию вместо динамической отправки, например, с интерфейсами). Концепции более открытые, поэтому их проще использовать.
Ответ 2
Классы - это форма именованного соответствия. Вы указываете, что класс Foo соответствует интерфейсу I, наследуя от I.
Концепции - это форма структурного и/или выполнения времени. Класс Foo не должен указывать фронт, какие концепции он соответствует.
Результат состоит в том, что именованное соответствие уменьшает возможность повторного использования классов в местах, которые не ожидались впереди, даже если они были бы полезны.
Ответ 3
Концепции на самом деле не являются частью С++, это просто концепции! В С++ нет способа "определить понятие". Все, что у вас есть, это template и class es (STL - все классы шаблонов, так как имя говорит: S tandard T эмблема L Библиотека).
Если вы имеете в виду С++ 0x, а не С++ (в этом случае я предлагаю вам изменить тег), прочитайте здесь:
http://en.wikipedia.org/wiki/Concepts_(C++)
Некоторые части, которые я собираюсь скопировать для вас:
В ожидающей пересмотре С++ 0x языка программирования С++ концепции и связанное с ними понятие аксиом были предложены для расширения системы шаблонов С++, , предназначенной для улучшения диагностики компилятора и , чтобы позволяют программистам кодифицировать в программе некоторые формальные свойства шаблонов, которые они пишут. Включение этих ограниченных формальных спецификаций в программу (в дополнение к улучшению четкости кода) может помочь в оптимизации некоторых компиляторов, а может потенциально помочь повысить надежность программы с помощью инструментов официальной проверки чтобы убедиться, что реализация и спецификация действительно соответствуют.
В июле 2009 года комитет С++ 0x решил удалить концепции из проекта стандарта, поскольку они считаются "не готовыми" для С++ 0x.
Первичная мотивация внедрения понятий улучшает качество сообщений об ошибках компилятора.
Итак, как вы можете видеть, концепций не существует для замены интерфейсов и т.д., они просто помогают лучше оптимизировать компилятор и создавать лучшие ошибки.
Ответ 4
Пока я согласен со всеми опубликованными ответами, они, похоже, пропустили одну точку, которая является производительностью. В отличие от интерфейсов, концепции проверяются во время компиляции и поэтому не требуют вызовов виртуальных функций.
