С переводом лучше пораньше разобраться, тем более, что там все довольно просто. А так, чем дальше - тем больше потом переделывать придется .

Может сначала надо model->select() вызвать, а потом model->setHeaderData? Так и в справке написано.

C++ (Qt)
model->select();
model->setHeaderData(fio, Qt::Horizontal, tr("Ф.И.О."));
model->setHeaderData(otdel, Qt::Horizontal, tr("Отдел"));
model->setHeaderData(tel, Qt::Horizontal, tr("Телефон"));

И строки надо всегда писать латинскими буквами. Не надо туда пихать русские, тем более не в кодировке UTF-8. tr("......") предназначено для перевода с английского на другие языки, а не наоборот.

Предвосхищая вопрос: "А где этот фуфло брать? Его же тоже еще нет. Если все фуфлы создавать заранее, то вдруг они не понадобятся, и будут только место занимать.", предлагаю добавить фабрику фуфла: FufloFactory.

"ННН"... зачем Вы так буст зашифровали?

И в конце обязательно покажет правильный способ сериализации всея объектов во всея форматы .

Обязательно получите!
Шаблоны есть? Есть. Ссылки вместо указателей? А как иначе! Даже shared_ptr есть в комплекте с reference_wrapper. И самое главное: ни фига не понятно! Как с этим жить и как поддерживать. За что отдельный бонус от Igors .

Так а что передавать конструктору в качестве rootSegment (которого пока нет, он еще не загружен)? "Какое-то фуфло"?

А насколько плохо в качестве такого идентификатора использовать текущий адрес объекта в памяти? (Допустим, что памяти хватает и все нужные объекты там уже находятся).

А я вот и жду, узнаем мы наконец-то, что конкретно Вы собираетесь сериализовать и куда. Началось со структур по сети, потом "vectot<int>, vectot<float>", теперь и до полиморфных классов добрались. Или Вы хотите универсальный метод для всего сразу изобрести?

Шаблоны как раз исходный текст программы и сдувают . И направление в дусте весьма дельное. Жаль, что его разжевывать приходится.

Отличный способ, реализуйте . И как в дусте до такого не догадались... Наверное побоялись прилепить к каждой структуре базовый класс, да еще с виртуальным методом. И, чтобы отвести глаза, наваяли кучу шаблонов с макросами .

"Вы не понимаете!" (c)

Вполне нормальный пример. Для начала более чем достаточно, чтобы продемонстрировать направление. И копируйте код корректно, QDataStream совсем не iarchive находится.

Есть одно маленькое упущение: чтобы получить конструктивное решение, надо описать конструктивное задание . Потому как нет одного универсального метода, который ко всем случаям оптимально подойдет.

Поэтому повторюсь:

У меня примерно такие же аргументы были. И плюс, например, по контейнерам надо было выбирать. Все-таки чем-то одним надо пользоваться.

Смотрел туда одно время... На довольно низком уровне, для кроссплатформенности, похоже лучше и не найдешь библиотеки. Но хотелось уровень повыше и удобства, поэтому победил Qt . И буст таскать с собой не захотелось.

Выше уже сказали, что никто не заставляет использовать, а посмотреть на реализацию вполне стоит .

Если бы буст был так хорош, и его бы использовали в Qt, я бы тоже им пользовался безоговорочно. Но разработчики Qt не используют его, более того, изобретают свои велосипеды, взять хоты бы их контейнеры QVector, QList и т.п. Хотя, казалось бы, бери хоть из std, хоть из буста. Велосипеды Qt мне нравятся намного больше, чем другие. Поэтому я пользуюсь Qt и добавляю туда свои запчасти, и не использую буст. Но это не значит, что нельзя в бусте подглядывать интересные и полезные моменты .

Если коротко, то способ с переопределением операторов для QDataStream не будет работать для полиморфных классов. Например:

C++ (Qt)
class A {};
class B : public A {};
 
QDataStream & operator<< (QDataStream& stream, const A& a);
QDataStream & operator>> (QDataStream& stream, A& a);
 
QDataStream & operator<< (QDataStream& stream, const B& b);
QDataStream & operator>> (QDataStream& stream, B& b);
 
main
{
  A* b = new B();
 
 QDataStream out(&file);
 out << *b; // Call QDataStream & operator<< (QDataStream& stream, A& a);
}

будет записана только часть класса А, поля В сохранены не будут. Потому что используемый шаблон выбирается в compile-time, и компилятор не знает, какой фактически объект будет в run-time. Если у вас есть дочерние ноды, они создаются динамически и в compile-time их конкретный тип не известен, то Вас ожидают такие вот грабли . И есть еще много других .

В способе буста тоже не все так безоблачно, стоить посмотреть Pointers to Objects of Derived Classes. Я о таком подозревал, и когда увидел это, стало еще тоскливее...