Базовые классы в сравнении с шаблонами, сгенерированный код и макросы.

Question

Мне нужно разработать небольшую рамку, которая будет использоваться несколькими нашими приложениями. Кроме того, фреймворк будет использоваться несколько раз в одном приложении, но с немного другой конфигурацией. «Природа» конфигурации более сложна, чем просто наличие некоторых параметров конфигурации и некоторых настроек. На практике приложение должно предоставлять свои собственные структуры данных, которые будут включены в структуру, что делает его еще более сложным.

Я вижу следующие 4 варианта написания фреймворка:

• Поместите общую логику в базовый класс и сообщите приложению, что оно должно наследоваться от этого базового класса
• Поместите логику в шаблонный класс, в котором приложение должно передать собственную реализацию класса
• Опишите конкретную конфигурацию приложения в файле конфигурации и сгенерируйте код C ++ во время процесса сборки
• Укажите макросы, которые можно использовать для расширения «конфигурации» до фактического кода

Какие аргументы следует учитывать при выборе хорошей альтернативы?

Некоторые из этих альтернатив лучше других и почему?

Обратите внимание, что в моем случае производительность является главным приоритетом.

Answer 1

Я бы избегал полимофизма во время выполнения, если бы пиковая производительность действительно была проблемой не только потому, что поиск в виртуальной таблице для вызовов виртуальных функций, но и потому:

• Встраивание виртуальных вызовов для обеспечения эффективной межграничной оптимизации границ довольно сложно сделать (то же самое относится к сгенерированному коду, скомпилированному в общую библиотеку, загруженную во время выполнения («плагин»), и статически связанным модулям, скомпилированным из сгенерированного кода с использованием компилятора. который не поддерживает оптимизацию времени ссылки).
• полиморфные объекты обычно должны быть выделены в куче, чтобы избежать нарезки, что может привести к дополнительным накладным расходам во время выполнения

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

Answer 2

Что вы подразумеваете под производительностью? Если это производительность выполняемого финального кода, помните, что решение с наследованием классов, которое включает виртуальную функцию, потребует небольших накладных расходов при их вызове.

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

Answer 3

Использовать заголовочный файл для конкретной платформы.Это дополнительная альтернатива, похожая на макросы, но без излишеств.

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