Здравствуйте!

Подскажите, пожалуйста в каком направлении двигаться в реализации следующего класса
1. Класс представляет собой сервис, который может использоваться на различных платформах
2. Имеет одинаковый интерфейс для всех платформ
3. Реализация зависит от платформы и определяется на этапе компиляции
4. Пользовательская программа использует класс в виде, независимом от платформы

В данном контексте платформа — совокупность программных и аппаратных средств, необходимых для функционирования сервиса.

Возможно ли это сделать средствами C++ без использования условной компиляции?

Здравствуйте, Vasya777, Вы писали:

V>Подскажите, пожалуйста в каком направлении двигаться в реализации следующего класса
V>1. Класс представляет собой сервис, который может использоваться на различных платформах
V>2. Имеет одинаковый интерфейс для всех платформ
V>3. Реализация зависит от платформы и определяется на этапе компиляции
V>4. Пользовательская программа использует класс в виде, независимом от платформы
V>В данном контексте платформа — совокупность программных и аппаратных средств, необходимых для функционирования сервиса.

Pimpl idiom ака глупый указатель является стандартной парадигмой для данной ситуации.

V>Возможно ли это сделать средствами C++ без использования условной компиляции?
Да: подключая разные файлы на разных платформах.

Здравствуйте, Vasya777, Вы писали:

V>В данном контексте платформа — совокупность программных и аппаратных средств, необходимых для функционирования сервиса.

V>Возможно ли это сделать средствами C++ без использования условной компиляции?
Пользователь может "конфигурировать" сервис в компайлтайм под конкретную платформу или ты поставляешь ему только чистый интерфейс?

Здравствуйте, B0FEE664, Вы писали:

BFE>Pimpl idiom ака глупый указатель является стандартной парадигмой для данной ситуации.

А это можно сделать, если вся память для сервиса должна быть выделена статически на этапе компиляции?

V>>Возможно ли это сделать средствами C++ без использования условной компиляции?
BFE>Да: подключая разные файлы на разных платформах.

То есть использовать различные условия сборки проекта?

Здравствуйте, Kernan, Вы писали:

K>Пользователь может "конфигурировать" сервис в компайлтайм под конкретную платформу или ты поставляешь ему только чистый интерфейс?

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

Здравствуйте, Vasya777, Вы писали:

BFE>>Pimpl idiom ака глупый указатель является стандартной парадигмой для данной ситуации.
V>А это можно сделать, если вся память для сервиса должна быть выделена статически на этапе компиляции?
Можно использовать placement new с зарезервированным буфером в статической памяти. У вас что, реал-тайм приложение? Чем вам обычный способ не угодил?

Может вам это поможет: http://habrahabr.ru/post/111602/

V>>>Возможно ли это сделать средствами C++ без использования условной компиляции?
BFE>>Да: подключая разные файлы на разных платформах.
V>То есть использовать различные условия сборки проекта?
Нет, просто под каждую платформу написать свой Makefile/project-файл в котором подключать соответствующий для данной платформы файл. Но можно сделать и через ifdef.

У нас в конторе поддерживается две версии реализации boost/posix под различные платформы Windows/MacOS/Linux. Выбор boost/posix задаётся через ifdef и параметры компилятора, а реализация для платформ разнесена по файлам.
Типа такого:

TransportInterface.hpp — здесь описан интерфейс,

а в этих файла реализацию под конкретную конфигурацию:
TransportInterface_asio.cpp
TransportInterface_eddy25.cpp
TransportInterface_posix.cpp

Здравствуйте, Vasya777, Вы писали:

V>Здравствуйте, Kernan, Вы писали:

K>>Пользователь может "конфигурировать" сервис в компайлтайм под конкретную платформу или ты поставляешь ему только чистый интерфейс?

V>Некоторые константы необходимо определить во время компиляции через директивы препроцессора. Пользователь сам должен произвести сборку в отдельную библиотеку или со своей программой.
Тогда посмотри в сторону подхода Policy и Traits (всё есть у Александерску). Только сразу предупреждаю, если увлечёшься, то получишь монстроидальный код

Здравствуйте, B0FEE664, Вы писали:

<>

Думаю мне будет достаточно сделать так, как в первом варианте приведённой вами статьи. Всю реализацию скомпоновать по папкам и компилировать разные папки в зависимости от используемой платформы. Тогда разные разработчики могут спокойно заниматься своими реализациями. А пользовательский код всегда будет оставаться неизменным.

Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, Vasya777, Вы писали:

V>>Здравствуйте, Kernan, Вы писали:

K>>>Пользователь может "конфигурировать" сервис в компайлтайм под конкретную платформу или ты поставляешь ему только чистый интерфейс?

V>>Некоторые константы необходимо определить во время компиляции через директивы препроцессора. Пользователь сам должен произвести сборку в отдельную библиотеку или со своей программой.
K>Тогда посмотри в сторону подхода Policy и Traits (всё есть у Александерску). Только сразу предупреждаю, если увлечёшься, то получишь монстроидальный код

Главное, чтобы он был предсказуемым. Все эти фокусы с шаблонами могут плохо закончится. Тем более получается все разработчики должны владеть этой техникой. По вашему опыту насколько оправданны эти приёмы?

Здравствуйте, Vasya777, Вы писали:

V>Здравствуйте, Kernan, Вы писали:

K>>Здравствуйте, Vasya777, Вы писали:

V>>>Здравствуйте, Kernan, Вы писали:

K>>>>Пользователь может "конфигурировать" сервис в компайлтайм под конкретную платформу или ты поставляешь ему только чистый интерфейс?

V>>>Некоторые константы необходимо определить во время компиляции через директивы препроцессора. Пользователь сам должен произвести сборку в отдельную библиотеку или со своей программой.
K>>Тогда посмотри в сторону подхода Policy и Traits (всё есть у Александерску). Только сразу предупреждаю, если увлечёшься, то получишь монстроидальный код

V>Главное, чтобы он был предсказуемым. Все эти фокусы с шаблонами могут плохо закончится. Тем более получается все разработчики должны владеть этой техникой. По вашему опыту насколько оправданны эти приёмы?
Всё зависит от того, что тебе надо. Шаблонный код даст проверку в compile-time, позволит задавать какие-то констанаты во время компиляции, хороший шаблонный код может работать быстрее за счёт оптимизаий. Если зочется сделать всё просто быстро, то лучше использовать Фабрику/PImpl и не париться.
По моему опыту лучше не давать использовать такие инструменты евангелистам Александреску, т.к. они отведут душу на вашем проекте.

Здравствуйте, Vasya777, Вы писали:

V>Здравствуйте!

V>Подскажите, пожалуйста в каком направлении двигаться в реализации следующего класса
V>1. Класс представляет собой сервис, который может использоваться на различных платформах
V>2. Имеет одинаковый интерфейс для всех платформ
V>3. Реализация зависит от платформы и определяется на этапе компиляции
V>4. Пользовательская программа использует класс в виде, независимом от платформы

V>В данном контексте платформа — совокупность программных и аппаратных средств, необходимых для функционирования сервиса.

V>Возможно ли это сделать средствами C++ без использования условной компиляции?

pure virtual class?

class MyClassInterface
{
  public:
    virtual void do() = 0;
};

///
class WinMyClass
  : public MyClassInterface
{
public:
  void do() override;
};

///
class MacMyClass
  : public MyClassInterface
{
public:
  void do() override;
};

для создания класса используется функция которая экспортируется из dll

подход, является самым надежным и легко-читаемым(понимаемым)

имеет недостаток — виртуальный вызов функции (если вызов функций не частый, это не значительно)

Здравствуйте, Vasya777, Вы писали:

V>Главное, чтобы он был предсказуемым.
Тут с предсказуемостью как раз все в порядке, т.к. все проверяется в статике.
V>Все эти фокусы с шаблонами могут плохо закончится.
Почему? Нет там никаких фокусов.
V>Тем более получается все разработчики должны владеть этой техникой.
Там нет ничего сложного, все это легко осваивается. Главное воспринимать это как одну из техник, а не как панацею.
V>По вашему опыту насколько оправданны эти приёмы?
Вполне оправданы, если сильно не увлекаться и не злоупотреблять.

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