Для меня правда понятие концепт больше похож на
-----
Как определен концепт - совершенно не принципиально. Могу накидать хоть заголовоки классов с комментариями в качестве определений.
Если разрешено то делаем, если не разрешено то не делаем, если непонятно спрашиваем автора\шефа как требуется\хочется.
-----
Именно это и написано в концепте. Одновременно - требуется и запрещено. Требуется, потому что для чистой виртуальной функции концептом требуется обязательная имплементация. И - запрещено, потому что чистый класс не имеет полей и имплементация вырождается в пустую виртуальную функцию. Требование, кстати, совершенно логичное, при условии что чистый класс всегда агрегируется.
то эти данные не "нужны"
------
Угу... именно по-этому концепт запрещает создание пустых виртуальных методов, требуя, однако, наличия метода или обработки ошибки вызова в контексте объекта. Фактически, наличие этой ситуации определяет, что в построении иерархии классов допущена ошибка.
Я знаю :) Кодогенератор мурра!
------
Кодогенератор Мурр'а тебе тут не поможет. Ищи другой тоолс... :)
Вот если каждая фигура имеет специфические аттрибуты\операции тогда можно подумать.
-----
Имеет. Но это не поля(аттрибуты) так как поля не разрешены концептом для чистых классов. Она определяет необходимое и достаточное условие существования фигуры. В противном случае тебе придется определять их во внешнем коде, что концепт косвенно запрещает, требуя использования чистых классов на уровне приложения.
Обычно когда делается концепт имплементация уже известна.
-----
Концеп для того и делается, чтобы оценить требования и выбрать подходяций инструментарий. Бо, если есть имплементация, то написать всеохватывающий концепт практически невозможно из-за различий в деталях имплементации отдельных элементов.
Иначе какой смысл проектировать то, что нельзя нормально реализовать
------
Ну хотя бы чтобы оценить ограниченность С++ концепта... :)
Заодно - имплементация указанного концепта средствами Сей, отличается от имплементации эмуляции виртуальных функций всего в двух местах - одно дополнительное поле - признак чистой виртуальной функции - в таблице виртуальных функций и дополнительная проверка этого поля при отработке ошибочного вызова... Собственно для демонстрации этого Я и написал концепт, не вписывающийся в С++ реализацию, но без проблем реализуемый в Сях. :)
===========
\Тогда ты их имплементируешь и не вызываешь.
Я имел в виду, что их компайлер их за меня вызывает.
-----
И new & delete ты сам никогда не пишешь? ;-) Вот их и заменяешь на вызовы.
Так а если структура мне нужна, точнее только часть структуры?
-----
В ООП? ;-)
А почему я обязан использовать динамическую аллокацию?
------
А у тебя есть выбор при использовании new & delete ?
я не вижу причины почему для статически создаваемых объектов не должен вызываться конструктор
------
А он "вызывается". На этапе трансляции. В результате объект полностью определен и аллоцирован. Виртуальность конструктора в данном случае как раз запрещает это делать и принуждает выполнять реальный вызов.
это проблематично уже по определению
------
И тем не мение даже в C# можно в конструкторе ссылаться на себя, хотя объект еще не готов, все транслируется... и валится на выполнении.