Сериализация (как сделать поудобнее)

[ViTech]

Все структуры взаимосвязаны.
Фактически они являются нодами огромнейшей системы. Каждая нода может ссылаться на данные, на другую ноду, быть объединённой с другой нодой. Имеются ноды различных типов, начиная от физ устройства, заканчивая виртуальными узлами. Собственно получается этакий чоООООрный круг. Что на самом деле не круг, а граф связей между ними

Да, ссылок может быть несколько

Если коротко, то способ с переопределением операторов для 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. Я о таком подозревал, и когда увидел это, стало еще тоскливее...

[ViTech]

Так почему бы не сказать проще "используй сериализацию буста, там давно за тебя все сделали". Однако не все спешат это делать - хотя сериализация есть у каждого. Был слушок что там проблемы с версиями - правда никаких подробностей не знаю. Да и просто перелопатить с Archive множество живых классов как-то не тянет. Да, в Qt кое-чего нет, так что, сразу привлекать др либу? Может и свои решения будут неплохи (или такая мысль не допускается?  )

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

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

[Bepec]

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

[Old]

Если бы буст был так хорош, и его бы использовали в Qt,

Ну в обще-то буст очень хорошо, очень-очень. А не используют его в Qt совсем по другим причинам. Велосипеды в Qt свои, потому что в те времена, когда его начинали разрабатывать не было даже нормальной поддержки строк. Плюс Тролли хотели полной автономности и лишние зависимости были просто не нужны.

И да, если когда нибудь, не дай Бог конечно, вам придется писать софт без Qt обратите внимание на буст. Он многое предоставляет.

[ViTech]

Плюс Тролли хотели полной автономности и лишние зависимости были просто не нужны.

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

И да, если когда нибудь, не дай Бог конечно, вам придется писать софт без Qt обратите внимание на буст. Он многое предоставляет.

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

[Old]

И буст таскать с собой не захотелось.

Большинство бустовских библиотек просто разворачиваются в коде, т.е. таскать с бинарником разделяемые библиотеки не нужно. К тому же его всегда можно собрать статически.

[Igors]

А как насчет того чтобы вернуться к теме?   Я согласен со всем что сказали ViTech и Old, но согласитесь, конструктивных решений это никак не прибавляет. Что мы имеем? Ну мой (сопливый) вариант, систему sergek (которой пока не понял) и... что еще?

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

Негусто. Или я что-то упустил?

[Bepec]

Плохо читаете

1) Сериализация с использованием шаблонов (Igors)
2) Строковые идентификаторы для каждой переменной (sergeich)
3) Объединение включающее структуру и массив байт (данные всегда находятся в виде массива байтов, ничего сериализовать и десериализовывать не надо) (Bepec)
4) Переопределение операторов << и >> с простейшим упихиванием всего в QDataStream  (Bepec)
5) Использование готовых библиотек сериализации (boost, s11n). Правда описывать сериализатор и десериализатор тоже нужно
6) Написание своего сериализатора и десериализатора для каждого объекта. На выходе получаем стандартный контейнер (alexis)
7) Написание отдельных сериализаторов для каждого алгоритма сериализации (XML) и подключение их по мере необходимости (ViTech)

[Igors]

3) Объединение включающее структуру и массив байт (данные всегда находятся в виде массива байтов, ничего сериализовать и десериализовывать не надо) (Bepec)

От этого меня отучили еще когда понадобилось гонять данные между  PPC и Intel. Причем понимание что так делать плохо приходит быстро и навсегда По поводу остального

Вы сказали много интересного и нового. Но интересное не ново, а новое не интересно

 

[alexis031182]

Получается, Верес победил. У него больше всего вариантов

[Bepec]

В любом случае всё разбивается на три кучки:

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

3) Объединение включающее структуру и массив байт (данные всегда находятся в виде массива байтов, ничего сериализовать и десериализовывать не надо) (Bepec)
4) Переопределение операторов << и >> с простейшим упихиванием всего в QDataStream  (Bepec)
6) Написание своего сериализатора и десериализатора для каждого объекта. На выходе получаем стандартный контейнер (alexis)

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

5) Использование готовых библиотек сериализации (boost, s11n). Правда описывать сериализатор и десериализатор тоже нужно Улыбающийся

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

1) Сериализация с использованием шаблонов (Igors)
2) Строковые идентификаторы для каждой переменной (sergeich)
7) Написание отдельных сериализаторов для каждого алгоритма сериализации (XML) и подключение их по мере необходимости (ViTech)

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

[ViTech]

Негусто. Или я что-то упустил?

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

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

Так это смотря что сериализовать, как и куда.
...есть ли наследование в этих структурах и т.п....

[Old]

Негусто. Или я что-то упустил?

Хорошо, давайте добавим немного кода:

Код

C++ (Qt)
#ifndef serialize_h
#define serialize_h
 
#include <QDataStream>
 
class archive
{
public:
	enum rw_mode { read, write };
 
	virtual ~archive() {};
	virtual rw_mode	mode() const = 0;
};
 
class iarchive : public archive
{
public:
	rw_mode	mode() const { return read; }
};
 
class oarchive : public archive
{
public:
	rw_mode	mode() const { return write; }
};
 
class qds_iarchive : public iarchive
{
public:
	qds_iarchive( QIODevice *dev ) : m_stream( dev ) {}
 
	template<typename T>
	qds_iarchive &operator&( T &data )
	{
		m_stream >> data;
		return *this;
	}
 
private:
	QDataStream		m_stream;
};
 
class qds_oarchive : public iarchive
{
public:
	qds_oarchive( QIODevice *dev ) : m_stream( dev ) {}
 
	template<typename T>
	qds_oarchive &operator&( const T &data )
	{
		m_stream << data;
		return *this;
	}
 
private:
	QDataStream		m_stream;
};
 
#endif // serialize_h
 

Код

C++ (Qt)
#include <QCoreApplication>
#include <QFile>
#include <QDebug>
#include "serialize.h"
 
int main( int argc, char *argv[] )
{
	QCoreApplication app( argc, argv );
 
	{
		QFile file( "test.dat" );
		if( !file.open( QIODevice::WriteOnly ) )
		{
			qWarning() << "File open error (write)";
			return 1;
		}
 
		qint8  a = 0x10;
		qint16 b = 0x20;
		qint32 c = 0x30;
 
		qds_oarchive os( &file );
		os & a;
		os & b;
		os & c;
	}
 
	{
		QFile file( "test.dat" );
		if( !file.open( QIODevice::ReadOnly ) )
		{
			qWarning() << "File open error (read)";
			return 1;
		}
 
		qint8  a;
		qint16 b;
		qint32 c;
 
		qds_iarchive is( &file );
		is & a;
		is & b;
		is & c;
 
		qDebug() << hex << a << b << c;
	}
 
	return 0;
}
 

[panAlexey]

Хорошо, давайте добавим немного кода:

Код

C++ (Qt)
		qDebug() << hex << a << b << c;
 

а это что: qDebug() << hex << a << b << c; ??

[Old]

а это что: qDebug() << hex << a << b << c; ??

Манипулятор. Для печати в 16-ричной системе.