Я вот о чём:

C++ (Qt)
QVector<MyClass> vector;
out << vector;
 
QVector<YourClass> vector;
for (auto & elem : vector)
{
    elem.write(out);
}
 

Я выбираю первый вариант.

Но это как раз и означает, что операторы >> << должны быть определены в контексте MyClass, т.к. сериализация QVector<T> явно требует этого. И для этого ВНЕШНИЕ классы в принципе не нужны.

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

Методы сериализации реализуются с помощью специализаций шаблонов

C++ (Qt)
template < typename _Archive, typename _Value, int _version >
struct Serializer;
template < typename _Archive, typename _Value, int _version >
struct Loader;
template < typename _Archive, typename _Value, int _version >
struct Saver;
 

Для простоты объяснения понятие версии опущу.

По умолчанию реализация методов выглядит так

C++ (Qt)
template < typename _Archive, typename _Value >
struct Serializer
{
    static void invoke ( _Archive & archive, _Value & value )
    {
        archive.corrupt( value );
    }
};
 
template < typename _Archive, typename _Value >
struct Loader
{
    static void invoke ( _Archive & archive, _Value & value )
    {
        Serializer< _Archive, _Value >::invoke( archive, value );
    }
};
 
template < typename _Archive, typename _Value >
struct Saver
{
    static void invoke ( _Archive & archive, const _Value & value )
    {
        Serializer< _Archive, _Value >::invoke( archive, const_cast< _Value & > ( value ) );
    }
};
 

По умолчанию, Loader и Saver вызывают один и тот же метод Serializer::invoke, и если методы сериализации и десериализации ни чем не отличаются (как это обычно и бывает), то достаточно специализировать только Serializer. Если отличия существуют из-за геттеров и сеттеров, например, то специализировать придется и Loader, и Saver (Serializer специализировать в этом случае не требуется).

Предположим, что нам необходимо сериализовать структуру

C++ (Qt)
struct SimpleStruct
{
    int m_int;
    double m_double1;
    double m_double2;
};
 

Для этого необходимо специализировать один единственный метод сериализации

C++ (Qt)
template < typename _Archive >
struct Serializer< _Archive, SimpleStruct >
{
    static void invoke ( _Archive& archive, SimpleStruct & value )
    {
        archive
            .serialize( value.m_int )
            .serialize( value.m_double1 )
            .serialize( value.m_double2 );
    }
};
 

Таким образом, один метод реализует и сериализацию и десериализацию. Но как и куда?
Здесь определяющую роль играет понятие архива. Архив - это ваш произвольный класс реализующий интерфейс для сериализации

C++ (Qt)
class OutputArchive
{
public:
    template < typename _Value >
    Archive & serialize ( const _Value & value );
 
    template < typename _Value >
    void corrupt ( const _Value & value, int version );
};
 

или для десериализации

C++ (Qt)
class InputArchive
{
public:
    template < typename _Value >
    Archive & serialize ( _Value & value );
 
    template < typename _Value >
    void corrupt ( _Value & value );
};
 

Куда/откуда и как происходит сохранение/чтение параметров решает разработчик архива.

Архив может сериализовать в std::stream, в QDataStream, в QTextStream, в разных форматах - XML, JSON, BIN и т.п. и т.д.

Для сериализации данных контейнеров типа std::vector, QVector для этих типов так же необходимо реализовать специализацию Serializer.

Для наглядности - пример архива

C++ (Qt)
 
class XmlOArchive
{
private:
    QTextStream m_stream;
 
public
    XmlOArchive ( QIODevice * device )
    : m_stream( device )
    {
        m_stream.setCodec( "utf-8" );
        // ...
    }
 
public:
    template < typename _Value >
    Archive & serialize ( _Value & value )
    {
        QByteArray open_tag = "<Value>"
        QByteArray close_tag = "</Value>";
        m_stream << open_tag;
        Loader< _Value >::invoke( *this, value );
        m_stream << close_tag;
        return *this;
    }
 
    // Specialize for all POD types, for example.
    Archive & serialize ( int value )
    {
        QByteArray open_tag = "<Int>"
        QByteArray close_tag = "</Int>";
        m_stream
            << open_tag
            << value
            << close_tag;
        return *this;
    }
 
    template < typename _Value >
    void corrupt ( _Value & value )
    {
         qWarning() << "Archive corrupted";
    }
}
 
 

Доступ к приватным членам, нужен не часто, при правильной реализации должно хватать API класса.
Но если этого нет, можно использовать friend зависимости.

Да, обобщить "туды-сюды" у меня руки так и не дошли. Интересно, спасибо

Такой момент: вот "простейший пример"

C++ (Qt)
stream << a << b << c;

И типа "ну вот и вся сериализация" (одним движением). Однако это предполагает жесткий, неизменный порядок следования данных, все они должны быть прочитаны. Также ничего не известно о типе данных, мы должны полагаться что a (b, c) - именно данные тех самых типов что мы хотим. Поэтому так работает хорошо для относительно простых, базовых структур. В более сложных случаях данные должны быть идентифицированы и могут быть сериализованы в различном порядке. Как Вы решаете эту проблему?  

Может не самый лучший пример - не припомню когда мне была нужна только 5-я запись Зато

C++ (Qt)
stream >> a >> b >> c;  // было так (версия 1.0)
stream >> a >> a1 >> b >> c;  // появилась новая структура (версия 1.1)
stream >> a >> b >> x >>  c;  // неизвестная структура "x" (версия 1.0 читает данные записанные в 2.0)
 

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

Но все равно, основательно у Вас в конторе сделано. Спасибо

Здесь имеется ввиду, что при изменении версии структуры, ее новые данные сериализуются по новым ключам, а удаленные можно не сериализовать совсем.
Тогда старое ПО легко может частично десериализовать новую структуру и не "сломается". В линейном случае так легко это не прокатит.
Хорошим примером такого подхода является protobuf.


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

У нас версию имеет не архив, а сама структура. Это может показаться накладно, однако такой подход обеспечивает бинарную совместимость между различными версиями ПО. Это важно, например, когда ПО состоит из множества разных процессов, взаимодействующих между собой, а при обновлении система не может быть остановлена.


Это и есть параметризация, когда данные пакуются по ключам.