C++ обработка конкретного impl - #ifdef vs private inheritance vs tag dispatch

вы можете использовать подход на основе политики с шаблонами, как это делает стандартная библиотека для распределителей, компараторов и тому подобное. Каждая реализация имеет класс политики, который определяет computeSome () и computeMore (). Ваш класс Algo принимает политику в качестве параметра и откладывает ее реализацию.

template <class policy_t>
class algo_with_policy_t {
    policy_t policy_;
public:
    algo_with_policy_t() { }
    ~algo_with_policy_t() { }

    void process()
    {
        policy_.computeSome();
        policy_.computeMore();
    }
};

struct altivec_policy_t {
    void computeSome();
    void computeMore();
};

struct sse_policy_t {
    void computeSome();
    void computeMore();
};

struct scalar_policy_t {
    void computeSome();
    void computeMore();
};

// let user select exact implementation
typedef algo_with_policy_t<altivec_policy_t> algo_altivec_t;
typedef algo_with_policy_t<sse_policy_t> algo_sse_t;
typedef algo_with_policy_t<scalar_policy_t> algo_scalar_t;

// let user have default implementation
typedef
#if defined(ALTIVEC)
    algo_altivec_t
#elif defined(SSE)
    algo_sse_t
#else
    algo_scalar_t
#endif
    algo_default_t;

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

template <class algo_t>
void use_algo(algo_t algo)
{
    algo.process();
}

void select_algo(bool use_scalar)
{
    if (!use_scalar) {
        use_algo(algo_default_t());
    } else {
        use_algo(algo_scalar_t());
    }
}

если накладные расходы виртуальной функции приемлемы, вариант 3 плюс несколько ifdefs кажется хорошим компромиссом IMO. Есть два варианта, которые вы могли бы рассмотреть: один с абстрактным базовым классом, а другой с простой реализацией C в качестве базового класса.

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

кроме того, наличие отдельных C++ и векторизованных версий вашего класса позволяет легко писать модульные тесты, которые

• убедитесь, что векторизованный код дает правильный результат (легко испортить это, и векторные плавающие регистры могут иметь разную точность, чем FPU, вызывая разные результаты)
• сравните производительность C++ против векторизованного. Часто бывает полезно убедиться, что векторизованный код действительно приносит вам пользу. Компиляторы могут создайте очень плотный код C++, который иногда делает так же или лучше, чем векторизованный код.

вот один с реализациями plain-c++ в качестве базового класса. Добавление абстрактного интерфейса просто добавит общий базовый класс ко всем трем из них:

// Algo.h:

 class Algo_Impl    // Default Plain C++ implementation
{
public:
     virtual ComputeSome();
     virtual ComputeSomeMore();
     ...
};

// Algo_SSE.h:
class Algo_Impl_SSE : public Algo_Impl   // SSE
{
public:
     virtual ComputeSome();
     virtual ComputeSomeMore();
     ...
};

// Algo_Altivec.h:
class Algo_Impl_Altivec : public Algo_Impl    // Altivec implementation
{
public:
     virtual ComputeSome();
     virtual ComputeSomeMore();
     ...
};

// Client.cpp:
Algo_Impl *myAlgo = 0;
#ifdef SSE
    myAlgo = new Algo_Impl_SSE;
#elseif defined(ALTIVEC)
    myAlgo = new Algo_Impl_Altivec;
#else
    myAlgo = new Algo_Impl_Default;
#endif
...

вы можете рассмотреть возможность использования шаблонов адаптеров. Существует несколько типов адаптеров, и это довольно расширяемая концепция. Вот интересная статья структурные картины: переходника и Façade это обсуждает очень похожий вопрос на тот, который в вашем вопросе-структура ускорения в качестве примера паттера адаптера.

Я думаю, что неплохо обсудить решение на уровне шаблонов проектирования, не фокусируясь на деталях реализации, таких как язык C++. После того, как вы решите, что адаптер указывает правильное решение для вас, вы можете искать варианты, специфичные для вашей имплементации. Например, в мире C++ известен вариант адаптера, называемый generic adapter pattern.

Это на самом деле не весь ответ: просто вариант одного из ваших существующих вариантов. В варианте 1 Вы предположили, что включаете algo_altivec.cpp &c. в Альго.cpp, но вы не должны этого делать. Ты можешь опустить Альго.cpp полностью, и ваша система сборки решает, какой из algo_altivec.cpp, algo_sse.СРР, и C. для того чтобы построить. Вы должны были бы сделать что-то подобное в любом случае, какой бы вариант вы ни использовали, так как каждая платформа не может скомпилировать каждую реализацию; мое предложение заключается только в том, что какой бы вариант вы выбираете, вместо того, чтобы иметь #if ALTIVEC_ENABLED везде в источнике, где ALTIVEC_ENABLED устанавливается из системы сборки, у вас просто есть система сборки, непосредственно решающая, компилировать ли algo_altivec.СРР. Это немного сложнее достичь в MSVC, чем make, scons, &c., но все еще возможно. Это обычное дело для переключения в целом каталоге, а не отдельных исходных файлов; то есть вместо algo_altivec.cpp и друзья, у вас будет платформа / altivec / algo.cpp, platform/sse / algo.cpp, и так один. Таким образом, когда у вас есть второй алгоритм, для которого вам нужны реализации для конкретной платформы, вы можете просто добавить дополнительный исходный файл в каждый каталог.

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

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

// --------------------- Algo.h ---------------------
#pragma once

typedef boost::shared_ptr<class Algo> AlgoPtr;

class Algo
{
public:
    static AlgoPtr Create(std::string type);
    ~Algo();

    void process();

protected:
    virtual void computeSome() = 0;
    virtual void computeMore() = 0;
};

// --------------------- Algo.cpp --------------------- 
class PlainAlgo: public Algo { ... };
class AltivecAlgo: public Algo { ... };
class SSEAlgo: public Algo { ... };

static AlgoPtr Algo::Create(std::string type) { /* Factory implementation */ }

обратите внимание, что поскольку классы PlainAlgo, AlivecAlgo и SSEAlgo определены в Algo.cpp, они видны только из этого блока компиляции и, следовательно, детали реализации скрыты от внешнего мира.

вот как можно использовать ваш класс:

AlgoPtr algo = Algo::Create("SSE");
algo->Process();

Мне кажется, что ваша первая стратегия с отдельными файлами C++ и#, включая конкретную реализацию, является самой простой и чистой. Я бы только добавил несколько комментариев к вашему Algo.cpp, указывающий, какие методы находятся в файлах #included.
например,

// Algo.cpp
#include "Algo.h"
Algo::Algo() { }

Algo::~Algo() { }

void Algo::process()
{
    computeSome();
    computeMore();
}

// The following methods are implemented in separate, 
// platform-specific files.
// void Algo::computeSome()
// void Algo::computeMore()

#if defined(ALTIVEC)
    #include "Algo_Altivec.cpp" 
#elif defined(SSE)
    #include "Algo_SSE.cpp"
#else
    #include "Algo_Scalar.cpp"
#endif

Шаблоны, подобные политике (mixins), прекрасны до тех пор, пока требование чтобы вернуться к реализации по умолчанию. Это runtime opeation и должно обрабатываться полиморфизмом времени выполнения. шаблон стратегии могу справиться с этим хорошо.

есть один недостаток такого подхода: Strategy-подобный алгоритм не может быть встроен. Такой inlining может обеспечить разумное улучшение представления в редких случаях. Если это проблема, вам нужно будет охватить более высокий уровень логика Strategy.