Хочу здоровый такой factory

Ничего не понятно. Вам нужно заполнить вектор объектами на основе XML?

static std::vector

Зачем тут static?

char *t1

Зачем сишка? Есть std::string.

BaseClass *

Сырые указатели - зло.

Это ad-hoc пример, детали не важны.

Есть сотня классов, есть XML, надо по нему заполнять Nodelist::objs. Хочется найти оптимальный подход к задаче.

Да, в objs - инстансы объектов.

Десериализация?

Почти.

Тут просто переход от парсера XML на awk и динамического кода, который постоянно ломается. По сути это дерево узлов параметров, но это для задачи не важно.

Я в подобных задачах делаю мапу фабрик:

typedef BaseClass* (*ObjFactory)(const XMLNode &n);
// ....
static std::map<std::string, ObjFactory*> FactoryMap;

Далее либо при декларации/описании классов (поможет макрос) регистрируем их фабрики (обычно статические методы самих классов), либо делаем отдельный класс/метод который регестрирует ВСЕ фабрики (либо часть так / часть так).

При парсинге делаем чтото типа:

auto it = FactoryMap.find( node.type );
BaseClass *b = it->second(node);

static нужен чтоб один экземпляр был. Сишка местами потому что embedded и сишка. Сырые указатели тут пофиг, так как оно один раз построится, потом живёт вечно.

Можно уж тогда использовать std::unordered_map вместо std::map, чтобы вместо красно-черного дерева строилась таблица хэшей

А как описывается регистрация вместе с декларированием класса? нет ли примера? Просто параметры у конструкторов разные, нет ли какой хитрости, чтобы меньше одинакового кода писать?

Остальное я понял, очень хороший для меня вариант, спасибо!

Ну тут уже может быть много вариантов (в зависимости от конкретного случая, компилятора и тд). Как правило в этом помогает:

__attribute__((constructor)) - для вызова статической функции при запуске програмы

Шаблоны (можете посмотреть на boost::function и boost::bind) - там какраз решается много проблем с переменым количеством аргументов

Ну и макросы со всякими ## и __VA_ARGS__ для работы с произвольным количеством аргументов.

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

Спасибо!

http://en.cppreference.com/w/cpp/language/parameter_pack

__attribute__((constructor))

Я понимаю надобность этого в C. Но в C++ это уже можно сделать стандартными способами:

#include <iostream>
using namespace std;

struct Abc {
  Abc() {
    cout << "Abc\n";
  }
} abc;

int main() {
  cout << "main\n";
}

напечатает:

Abc
main

Это уже дело вкуса, я не любитель плодить не используемых глобальных переменных, если их сделать static то можно получить ругань от компилятора (unused static variable), а при оптимизации (часто VC) он вообще их выкидывает и конструктор не отрабатывает ...

получить ругань от компилятора (unused static variable)

Это вряд ли, ведь на самом деле переменная используется — у неё вызывается конструктор. GCC, например, не ругается. Если сделать структуру простой структурой, то ругаться начнёт.

на C++ рефлексию не вводили. Поэтому asm + calling convention должны помочь.

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

Ну и, типа как выше уже предлагали, для N заранее известных типов - сделать так, чтобы конструктор принимал Node и сам решал как ему создавать инстанс на основе содержимого Node. Но это черезжопный метод и только если все N типов в твоём владении. А если не все типы твои - то городи вместо такого конструктора такой же Factory с развестистой иерархией.

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