Альтернативы директивам препроцессору

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

У вас будет

• MyClass.h
• MyClass_S60_2nd.cpp
• MyClass_S60_3rd. cpp

и так далее. Вы можете выбрать, какой файл CPP компилировать, либо заключив его внутрь с помощью #ifdefs, как указано выше, либо я контролирую на уровне сборки (через Makefiles или что-то еще), какие файлы включаются при сборке для различных целей.

В зависимости от характера изменений это может быть намного чище.

Look at SQLite. They have the same problem. They move the platform-dependent stuff to separate files and effectively compile only needed stuff by having the preprocessor directives that exclude an entire file contents. It's a widely used approach.

В нашей компании мы пишем много кроссплатформенного кода (разработка игр для win32 / ps3 / xbox / и т. Д.).
Чтобы избежать макросов, связанных с платформой, насколько это возможно, мы обычно используем следующие несколько приемов:

• извлечение кода, связанного с платформой, в библиотеки абстракции платформы, которые имеют одинаковый интерфейс на разных платформах, но не одинаковую реализацию;
• split код в разные файлы .cpp для разных платформ (например: «pipe.h», «pipe_common.cpp», «pipe_linux.cpp», «pipe_win32.cpp», ...);
• используйте макросы и вспомогательные функции для унифицировать вызовы функций, специфичных для платформы (например: «#define usleep (X) Sleep ((X) / 1000u)»);
• использовать межплатформенные сторонние библиотеки.

Вы можете попробовать определить общий интерфейс для всех платформ, если это возможно. Затем реализуйте интерфейс для каждой платформы.

Выберите правильную реализацию с помощью директив препроцессора.

Таким образом, у вас будет директива выбора платформы в меньшем количестве мест в вашем коде (в идеале, в одном месте, явно в заголовке файл, объявляющий интерфейс).

Это означает что-то вроде:

commoninterface.h /* declaring the common interface API. Platform identification preprocessor directives might be needed for things like common type definitions */
platform1.c /*specific implementation*/
platform2.c /*specific implementation*/

There are several differences between S60 2nd ed and 3rd ed applications that are not limited to code: application resource files differ, graphic formats and tools to pack them are different, mmp-files differ in many ways.

Based on my experience, don't try to automate it too much, but have a separate build scripts for 2nd ed and 3rd ed. In code level, separate differences to own classes that have common abstract API, use flags only in rare cases.

Нет идей по поводу альтернативы, но что вы можете сделать, так это использовать разные файлы для включения в разные версии ОС. пример

#ifdef S60_2nd_ED

#include "graphics2"

#elif S60_3rd_ED

#include "graphics3"

#else

#include "graphics"

You could something like they do for the assembly definition in the linux kernel. Each architecture has its own directory (asm-x86 for instance). All these folders cluster the same high level header files presenting the same interface. When the kernel is configured, a link named asm is created targeting the appropriate asm-arch directory. This way, all the C files include files like .

Вам следует избегать распространения #if через код.

Скорее; используйте #if в файлах заголовков для определения альтернативных макросов, а затем в коде используйте единственный макрос.

Этот метод позволяет сделать код более читабельным.

Пример:

 Plop.h
 ======

 #if V1
 #define    MAKE_CALL(X,Y)    makeCallV1(X,Y)
 #elif V2
 #define    MAKE_CALL(X,Y)    makeCallV2("Plop",X,222,Y)
 ....
 #endif


 Plop.cpp
 ========

 if (pushPlop)
 {
     MAKE_CALL(911,"Help");
 }

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