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

Теперь я столкнулся с куском кода, которым вчера заспамил знакомых программистов, ибо сам понять просто не в состоянии:
Перво-наперво есть класс и вот такие макросы (указано в порядке обьявления в хедере!):
template <class _Abstract_T, typename _Key_T = PDefaultPFactoryKey>
class PFactory {
    template <class _Concrete_T>
    class Worker { /*...*/ };
    /*...*/
};

//
// this macro is used to initialise the static member variable used to force factories to instantiate
//
#define PLOAD_FACTORY(AbstractType, KeyType) \
  namespace PWLibFactoryLoader { \
    extern int AbstractType##_##KeyType##_loader; \
    static int AbstractType##_##KeyType##_loader_instance = AbstractType##_##KeyType##_loader; \
  };

//
// this macro is used to instantiate a static variable that accesses the static member variable
// in a factory forcing it to load
//
#define PINSTANTIATE_FACTORY(AbstractType, KeyType) \
  namespace PWLibFactoryLoader { int AbstractType##_##KeyType##_loader; }

Используется вся эта радость следующим образом:
/* Файл cpp */
class PProcessStartup { /*...*/ };
class PluginLoaderStartup : public PProcessStartup { /*...*/ };

static PFactory<PProcessStartup>::Worker<PluginLoaderStartup> pluginLoaderStartupFactory("PluginLoader", true);

// PString - внутренний аналог std::string
PINSTANTIATE_FACTORY(PluginLoaderStartup, PString)


Вопросы - как работают макросы? Каким образом происходит принудительное инстанцирование шаблона?
Да, возможно это ни что иное, как рога и копыта (а, говорят, разработчики этим очень грешат), но блин... Уж такое можно было бы и подчистить.

ЗЫ: куски взяты из свободной библиотеки ptlib 2.4.5.