[C++] Как бы вы оформили такое?

Сделай функцию шаблонной, параметризуй её этими самыми Object_A да Object_B и кто там ещё будет...

Нет, тут как раз смысл в том, чтобы попробовать разные протоколы для хоста и найти (ну, или не найти) подходящий. То есть перехватывать Protocol_Exception нужно для каждого Object_X, и пробовать следующий.

Лучше шаблоны используй. define в с++ зло

Избавит ли меня это от повторения одного и того-же кода?

template <class T>
Object_Ptr
magic_function(const std::string& host, uint16_t port)
{
    try {
        return Object_Ptr(new T(host, port));
    } catch (const Protocol_Exception&) {
        // nil
    }

    return Object_Ptr();
}

Object_Ptr create_object(const std::string& host, uint16_t port)
{
    Object_Ptr result;

    if (result == 0) {
        result = magic_function<Object_A>(host, port);
    }

    if (result == 0) {
        result = magic_function<Object_B>(host, port);
    }

    if (result == 0) {
        result = magic_function<Object_C>(host, port);
    }

    return result;
}

Эти #define'ы для опций сборки. У меня библиотека может быть собрана с поддержкой разных протоколов.

Тут я думаю поможет boost::mpl или препроцессор буста

я туплю.

создавай фабрики для каждого протокола, зарегестрируй их, а уж потом в цикле перебирай фабрики

А что насчёт

#ifdef WITH_PROTOCOL_B 
#define Obj_X Object_B
#endif// WITH_PROTOCOL_B 

А дальше один код на всё? Емнип, именно так это и делается

Я пока придумал нечто такое:

class Object_A
{
public:
    static Object_Ptr construct(const std::string&, uint16_t);
};

typedef boost::function<Object_Ptr (const std::string&, uint16_t)> Constructor;

typedef std::vector<Constructor> Constructor_Array;

Constructor_Array constructors;

void init_constructors()
{
#ifdef WITH_PROTOCOL_A
    constructors.push_back(boost::bind(&Object_A::construct, _1, _2));
#endif// WITH_PROTOCOL_A
#ifdef WITH_PROTOCOL_B
    constructors.push_back(boost::bind(&Object_B::construct, _1, _2));
#endif// WITH_PROTOCOL_B
}

Object_Ptr create_object(const std::string& host, uint16_t port)
{
    for (Constructor_Array::iterator iter = constructors.begin();
         iter != constructors.end(); ++iter)
    {
        try {
            return (*iter)(host, port);
        } catch (const Protocol_Exception&) {
            // Wrong protocol
        }
    }

    // No suitable protocol has been found
    return Object_Ptr();
}

> создавай фабрики для каждого протокола, зарегестрируй их, а уж потом в цикле перебирай фабрики

если протокол выбирается на этапе конпеляции — фабрика не нужна.

Что-то попахивает ересью. Покажи код, который вызывает create_object.

> Это выглядит чуть чише и проще, но не слишком сильно. Или про что ты говорил?

Да, что-то вроде этого я и имел в виду. Тут уже предложили фабрику наваять — можно и так попытаться.

>Есть ли какие-то общепринятые методы, идиомы и т.д., чтобы покрасивее такое сделать?

Шаблоны

навояй. на шаблонох просто будет. и у тебя только в одном месте будет разбор defin'ов, а потом данамически. или статически-типизированно-шаблонизированно

> протокол выбирается на этапе конпеляции

Не совсем так. Для определённости: есть куча разных видео серверов, каждый из которых работает по своему протоколу. Для каждого из них я знаю только хост и номер порта. Протокол предстоит определить во время исполнения. Библиотека предоставляет единый интерфейс для разных видео серверов, и может быть собрана с поддержкой разных протоколов, в зависимости от того, какие из них нужны и будут использоваться. Пользователь библиотеки делает такое: [code] Video_Server_Ptr video_server = create_video_server(host, port); [/code] Вся магия происходит внутри create_video_server, и пользователь работает с видео сервером через этот объект не заботясь о протоколах и т.п.

> Протокол предстоит определить во время исполнения. Библиотека предоставляет единый интерфейс для разных видео серверов, и может быть собрана с поддержкой разных протоколов, в зависимости от того, какие из них нужны и будут использоваться.

С этого надо было начинать. В таком случае намного красивее уже предложенных вариантов не сделаешь.

Я бы остановился на этом варианте.

во. то что надо

Кстати, нет ли в стандартной бибилиотеке или в boost'е подобного шаблона:

template <class Type,
          class Result_Type,
          class Argument_1_Type,
          class Argument_2_Type,
          class Argument_3_Type>
struct Generic_Creator
{
    Result_Type*
    operator()(const Argument_1_Type& arg_1,
               const Argument_2_Type& arg_2,
               const Argument_3_Type& arg_3) const
    {
        return new Type(arg_1, arg_2, arg_3);
    }
};

http://www.drdobbs.com/blog/archives/2010/06/the_x_macro.html;jsessionid=XFHI...

идиома

#define COLORS \
    X(red) \
    X(blue) \
    X(green)

#define X(a) C##a,
enum Color { COLORS };
#undef X

#define X(a) #a,
static char *ColorStrings[] = { COLORS };
#undef X

твой пример можно переписать так:

#define WITH_PROTO(NAME) \
#ifdef WITH_PROTOCOL_##NAME \
    try {  \
        return Object_Ptr(new Object_##NAME(host, port)); \
    } catch (const Protocol_Exception&) { \
        // nil \
    } \
#endif// WITH_PROTOCOL_##NAME

#define WITH_ALL_PROTOCOLS \
         X(A) \
         X(B) 


Object_Ptr create_object(const std::string& host, uint16_t port) 
{ 
#define X(a) WITH_PROTO(a)
WITH_ALL_PROTOCOLS
#undef X
}

Если внутри блока WITH_PROTO(х) понадобится «имя» х, используй #NAME вместо PREFIX##NAME

наверно, где-то есть, если поискать:

Of course, you may already be using a macro or variable named X, and X is hardcoded in the macro body. Andrei Alexandrescu suggests the following improvement where the X macro is itself a parameter:

#define FOR_ALL_COLORS(apply) \
apply(red) \
apply(blue) \
apply(green)
And later:

#define SELECT_STRING(a) #a,
static char *ColorStrings[] =
{ FOR_ALL_COLORS(SELECT_STRING) };
#undef SELECT_STRING

можно что-то накрутить с итераторами Буста

ну типичная фабрика же! паттерн http://ru.wikipedia.org/wiki/Абстрактная_фабрика_(шаблон_проектирования) или http://ru.wikipedia.org/wiki/Фабричный_метод_(шаблон_проектирования)

итого: constructors ты заполняешь на этапе конпеляции, а цикл идёт во время запуска программы. Этот цикл можно заменить на бустовый for_each, чтобы цикл развернулся во время конпеляции тоже.

А я бы сделал как-то так, без шаблонов:

#include <string>

class Object {};
class Object_A:public Object {};
class Object_B:public Object {};
class Object_C:public Object {};
typedef Object* Object_Ptr;

enum {ProtocolA=0,ProtocolB=1,ProtocolC=2};

inline Object_Ptr create_object(const std::string& host, uint16_t port,int protocol=ProtocolA) 
{ 
  try
  {
    if(protocol==ProtocolA)
    {
      return new Object_A();
    }
    else if(protocol==ProtocolB)
    {
      return new Object_B();
    }
    else if(protocol==ProtocolC)
    {
      return new Object_C();
    }
  }
  catch(int e)
  { 
        // nil 
  }
  return Object_Ptr(); 
} 


int main()
{
  Object_Ptr ptr = create_object("bla-bla-bla",666);
  return 0;
}

ага. и 100 строк кода if/return/else

>ага. и 100 строк кода if/return/else

Зато просто и интуитивно понятно. Хотя согласен. Для сотни вариантов лучше шаблоны.

Просто не есть понятнее

Понятнее для непрофи - это да

>Так-как функция inline и переменная protocol известна на этапе компиляции, то компилятор уберет лишнее.

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

я имел в виду create_object<int>(const std::string& host, uint16_t port)

>Понятнее для непрофи - это да

Это нечестный прием.

Шаблоны кстати тоже не панацея. Это компромисс между DSL и прямым написанием кода без фокусов с метапрограммированием.

Можно ведь сделать полноценный DSL. Тогда это совсем Ъ подход. Все будет предельно лаконично. Но этот подход потянет за собой другие проблемы.

зато как красиво код смотрится, ага http://blog.rafaelferreira.net/2008/04/couple-of-interesting-dsls.html

DSL на С++ --- вы извращенец

Хотя у меня достаточно специфичноиспользуемый c++ на работе

>DSL на С++ --- вы извращенец

Вы меня не поняли. Я не агитирую за DSL.

З.Ы. Сказанное можно понять, будто С++ избавляет от любой необходимости использовать DSL. Как я уже сказал в нем есть компромиссные решения, но не более того.