Очередная статья в Artima/The C++ Source:

Subscribing Template Classes with Object Factories in C++

Summary
Object factories provide a useful abstraction for object construction. A special problem with object factories must be considered, however, when subscribing template classes with object factories. This article presents an overview of the "subscription problem" along with several solutions.

Чесно говоря, я довольно смутно понял, в чем же суть рассматриваемой в статье проблемы (и ее отношение к практике). А вот способ ее решения не понял вовсе -- слишком много шаблонов. Поэтому и разбираться не особенно и хочется.

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

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

E>Чесно говоря, я довольно смутно понял, в чем же суть рассматриваемой в статье проблемы (и ее отношение к практике).

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

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

You will always get what you always got
  If you always do  what you always did

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

E>>Чесно говоря, я довольно смутно понял, в чем же суть рассматриваемой в статье проблемы (и ее отношение к практике).

J>Проблема очевидная: когда ты пишешь фабрику, ты должен как-то зарегистрировать в ней классы, с которыми она будет работать (Это должна быть не обязательно фабрика, просто класс, который общается с набором типов, например, класс, тестирующий другой шаблонный класс, или регистратор для эмуляции typeof, или подсистема сериализации, и т.п.).
J>Для обычных классов эта задача более-менее решена, но вот когда у тебя есть шаблонный класс, ты его зарегистрировать так просто не можешь — ты должен регистрировать конкретные инстанцирования. А таковых может оказаться очень много (комбинаторный взрыв по числу доступных типов, которыми может быть проинстанцировал класс), и писать регистрацию руками не очень весело.

Это понятно, не понятно, почему рассматривается шаблонный класс с двумя параметрами-политиками? Я так понял, что общего решения этой задачи для N параметров шаблонного класса у автора статьи нет.

J>Вся эта статья о том, как написать регистратор, чтоб просто одной строкой перечислить типы, с которыми будет инстанцироваться шаблон, и все его инстанцирования автоматически зарегистрировались.

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

Лично я решил бы эту проблему через внешний кодогенерирующий скрипт и подключение результатов его работы в код через #include.

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

E>Это понятно, не понятно, почему рассматривается шаблонный класс с двумя параметрами-политиками? Я так понял, что общего решения этой задачи для N параметров шаблонного класса у автора статьи нет.

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

E>Лично я решил бы эту проблему через внешний кодогенерирующий скрипт и подключение результатов его работы в код через #include.

Ну вот захотелось ему поизвращаться с шаблонами
Я бы эту задачу решал так ( пример из статьи плюс еще одна политика )

#define S1 (NoHide)(TimeoutHidding)(CHP)
#define S2 (NoDefense)(BulletProofed)(ShellProofed)
#define S3 (jazzer)(eao197)

#define MACRO(r, product) \
  factory->subscribe(Radar<BOOST_PP_SEQ_ENUM(product)>::ID(), \
                     createInstance<IRadar, Radar<BOOST_PP_SEQ_ENUM(product)> >);

Вот и все решение. Было бы из-за чего статью писать

You will always get what you always got
  If you always do  what you always did

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

J>Вот и все решение. Было бы из-за чего статью писать

Сорри, не все скопировал.
Вот полный код:

#include <boost/preprocessor/seq/for_each_product.hpp>
#include <boost/preprocessor/seq/enum.hpp>

#define S1 (NoHide)(TimeoutHidding)(CHP)
#define S2 (NoDefense)(BulletProofed)(ShellProofed)
#define S3 (jazzer)(eao197)
// и т.д.

#define MACRO(r, product) \
  factory->subscribe(Radar< BOOST_PP_SEQ_ENUM(product) >::ID(), \
                     createInstance<IRadar, Radar< BOOST_PP_SEQ_ENUM(product) > >);

BOOST_PP_SEQ_FOR_EACH_PRODUCT( MACRO, (S1)(S2)(S3)/*и т.д.*/ )

You will always get what you always got
  If you always do  what you always did

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

J>>Вот и все решение. Было бы из-за чего статью писать

Что ещё раз показывает: Александреску был великим человеком, но зачем же стулья ломать!
Там, где Loki вдохновляет на подвиги, решает boost.

И ещё кстати, о комбинаторном взрыве: boost/mpl здесь не пригодится ли? Хотя, конечно, когда уже на препроцессоре всё сделано, то mpl избыточно.