Тогда это либо неправильный концепт, либо нужно найти обходной маневр.
-----
Да нет, концепт - правильный. По крайней мере ты не указал ни одной нелогичности в концепте.
Просто данный концепт требует иметь в реализации два типа виртуальных функций с различным поведением. Примеряя его на С++ ты получаешь проблему - С++ предоставляет только один тип.
так и о концепте конкретной реализации
-----
Ты уверен, что сможешь создать концепт по конкретной реализации? Это примерно тоже, что по значению 4 обосновать что это было 2 + 2...
то почему бы не пользоваться ей.
------
Я уже предлогал оценить возможный тоолс для реализации заданного концепта. Прими как аксиому - Концепт - первичен, имплементация - вторична. И - имплементация, не соответствующая концепту не является имплементацией концепта.
То бишь плюсы сомнительны, а минусы очевидны.
------
Пока имеется обратная ситуация - концепт, как он определен, дает ощутимые преимущества, принуждая делать корректную имплементацию и позволяя превентивно избегать части архитектурных ошибок и быстро отслеживать часть ошибок имплементации. Очевиден только один минус - трудозатраты в реализации на С++ сравнимы с трудозатратами в Сях... :)
Лучше концепт подогнать под удобную реализацию.
-----
В Генераторе была сделана одна маленькая инновация - концептуально было установлено, что любая пара - источник данных + визуальный контрол - должены быть совместимы по обмену данными. Т.е. в любом месте пишем - контрол.значение = данные.значение - получаем отображение, пишем - данные.значение = контрол.значение - получаем сохранение пользовательского ввода. Объем кода, как шаблонов, так и продуцированного существенно снизился. Косвенно, отпала необходимость изменять шаблоны при введении новых контролов и источников данных, появилась возможность не думать об том как заменить тип контрола. Будем подгонять или делать имплементацию? :)
Но в этом случае части структуры должны быть недоступны для доступа.
-----
Перекрой доступ к структуре. Это же основная практика ООП - все через методы, никакого прямого доступа к данным.
Что мешает мне записать А а; вместо A* рa = new A;
-----
Ах, это... отвык - в СБилдере это просто не разрешается для копонентных классов. Придется писать вызовы, явно определяя время существования. Что поделаешь - небольшие издержки системы имплементации.
каким образом компилятор может проинициализировать объект, если конкретная память под него выделится только на этапе запуска программы
-----
Память под статический объект выделяется на этапе трансляции - размер области данных под класс компилятору известен, размещение таблицы виртуальных функций - тоже. Выделяется точно так же, как для любых статических переменных. Проблема только в одном - если внутри конструктора используется дополнительное, не С++, аллоцирование памяти, то оно не выполняется. Собственно отсюда появлся концепт синглентона в части замены статических элементов.
Но разве Мелкософт пользует виртуальные конструкторы?
-----
Понятия не имею. По возможности держусь... держался - до С#... подальше от поделок билли...