\Ну хорошо. Возьмем следующий концепт:
Для чего?
\Собственно, над вопросами работать тебе
Зачем? Чисто поиграться?
Для меня правда понятие концепт больше похож на УМЛ диаграмму, чем на сборник неизвестных словосочетаний.
\В данном месте у тебя должны возникнуть вопросы
Ничего не возникло, надо вначале в концепт въехать.
\Как имплементировать заглушки в грязных классах, все данные которых не используются в сериализации/десериализации?
Никто не определял ,что у нас только сериализации/десериализации. Но если "все данные которых не используются в сериализации/десериализации" то эти данные не "нужны" они не определяют состояние нашего объекта.
\Как имплементировать заглушки для чистых виртуальных методов в чистых классах, если их имплементация одновремнно требуется и запрещена концептом?
Если разрешено то делаем, если не разрешено то не делаем, если непонятно спрашиваем автора\шефа как требуется\хочется.
\А если я их не вызываю?
\-----
\Тогда ты их имплементируешь и не вызываешь.
Я имел в виду, что их компайлер их за меня вызывает.
\Недоступностью указателя на структуру. Просто физической невозможностью его получить.
Так а если структура мне нужна, точнее только часть структуры? Все запрятать можно, это скажем аналог прайвед. Либо скажем я делаю структуру снаружи, а не внутри.
\Плюсовый new в обязательном порядке выполняет динамическую аллокацию
А почему я обязан использовать динамическую аллокацию? Есть еще стек и статика. Конечно это прибъет хорошенько, но если низзя.
\А что он может быть виртуальным - само по себе не проблема.
Смотря как это определить. Если конструктор должен создать конкретный объект, а виртуальная фунция использует данные уже созданного объекта, то это проблематично уже по определению.
Можно правда определить "виртуальный" конструктор как конструктор создающий объекты "неизвестные" на этапе компиляции.
В любом случае, я не вижу причины почему для статически создаваемых объектов не должен вызываться конструктор, ведь при создании объекта нам просто нужен конструктор по определению. Другое дело, что для их вызова нужно хорошо извратится.
\Смотри заданный выше концепт и выбери наименее глючный тоолс для реализации... :)
Я знаю :) Кодогенератор мурра!
\Этот концепт ты в состоянии реализовать на С++, хотя будеш ругаться на необходимость отслеживать чистые виртуальные методы и писать заглушки на каждом уровне...
Не буду, я сам так иногда делаю, правда абстрация заканчивается на первом же уровне и это мне кажется это более правильным.
\Классы Треугольник, Прямоугольник, Трапеция, Пятиугольник являются чистыми, т.е. не содержат никаких элементов данных, но позволяют проверить и ограничить количество рисуемых отрезков.
Зачем? У меня есть Н выпуклый многоугольник он уже знает количество отрезков пусть и проверяет, в крайнем случае можно еще один класс заделать, а не новый на каждую фигуру. Вот если каждая фигура имеет специфические аттрибуты\операции тогда можно подумать.
\указать подходящее средство имплементации...
Обычно когда делается концепт имплементация уже известна. Иначе какой смысл проектировать то, что нельзя нормально реализовать. Хотя на первом этапе итерации этот вопрос и может возникнуть.