Добрый день

Навеяно этим
Конечно это безусловно верно. Но вот полей может быть много. Да, придется все записать, но хотелось бы сделать это 1 раз в не 2. А то выходит

C++ (Qt)
...
strm << mID;
strm << mName;
..  // еще десятки 
 
// а на др стороне
...
strm >> mID;
strm >> mName;
..  
 

Ну и если чего-то изменилось, сбивать 2 копии утомительно. Как бы это дело обобщить?

Спасибо

Я и спрашиваю как избежать повтора довольно большого куска в операторах >> и << для большой структуры

"Циля, он еще и поет" 

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

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

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

Ручки у барышень которые не работают Неужто все так безнадежно? Ну почему напр не так

C++ (Qt)
void MyStruct::ReadWrite( QDataStream & strm, bool modeWrite )
{
 ReadWriteInt(strm, &mID, modeWrite);
 ReadWriteQString(strm, &mName, modeWrite);
 ...
}

Да, в один метод это лучше не пихать, и по вышеназванной причине тоже. И вообще, лучше не делать это методом структуры, а создавать отдельно. Как, например, и рекомендуется в QDataStream, операторами. Потому что, в общем случае, структуру не должно волновать, кто и куда захочет ее сериализовать. QDataStream - это, конечно, хорошо, но вдруг кому захочется сохранять/загружать/передавать в XML/JSON/YAML/по сети/как-нибудь еще. Или, наоборот, кто-нибудь не будет пользоваться QDataStream, зачем ему эти методы в структуре?

А написать отдельные методы на чтение и на запись, не самое страшное, что есть в сериализации .

Я бы использовал отдельные файлы для каждого способа сериализаци для каждой структуры. Например:
Тот, кто будет читать/записывать, знает, каким способом он это сделает, подключит необходимые файлы и вызовет нужные функции. Может много хидеров подключить придется, зато ничего лишнего не будет. Можно и сгруппировать операции связанных структур в один файл, а не каждую в отдельный, но в общем смысл такой.

Рискну предложить свое решение – интерфейс удаленных вызовов, API. Объектное решение, работает уже лет 12 в одной биллинговой системе.
Общий подход следующий:
- архитектура клиент/сервер. Сервер запущен и слушает заданный порт, клиент соединяется с этим портом;
- обмен между клиентом и сервером осуществляется путем вызова особых функций на клиенте и получения результатов исполнения этих функций на сервере;
- аргументами функции и возвращаемым результатом служат указатели на объекты классов, порожденные от одного интерфейсного BoaInterface;
- объявления для классов и функций общие для клиента и сервера;
- реализации функций – свои для клиента и сервера:
  а) клиент выполняет передачу аргументов на сервер и прием результатов,
  б) сервер выполняет прием аргументов от клиента, выполнение бизнес-логики и передачу результатов клиенту.

Пример использования:
1) объявления классов и функций (общие для клиента и сервера):
2) реализация класса (тоже общая для клиента и сервера):
3) реализация клиентской функции:


4) реализация серверной функции:


В общем-то, и все. Вся сериализация скрыта в методах базового класса BoaInterface::send() и BoaInterface::receive(), сериализуются все основные типы и некоторые встроенные предопределенные типы.
Остальное одинаково для всех программ – организация соединения со стороны клиента, прослушивание порта со стороны сервера. Есть нюансы для win- и nix-реализации. Один раз пишется и переносится из проекта в проект.
Более того, процесс написания можно автоматизировать. В свое время даже хотел написать визард для генерации кода (stub/sckeleton), но, поскольку, писал все программы сам, для себя поленился. Есть встроенная поддержка BDE и PostgreSQL, правда, древней версии. Возможен callback из серверной функции на клиента.
Если заинтересует, библиотеку можно найти по адресу http://www.freesoft.ru/?id=671951. Полная документация (руководство программиста, справочник), примеры для Borland C++Builder и Qt в Windows и Unix. Правда, давно не компилировал под nix-системами (последний раз проверял под FreeBSD 4.5 и Fedora 10 (или 12?).
Но если кого заинтересует, проверю в ubunta 12.04.01.

В принципе ничего нового, кроме шаблонного метода Igors.

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

// шаблоны понимаю с трудом

Другой вопрос, что замена месторасположение одного поля или добавление самописного типа приведёт в любом случае к "ручной" правке.

to Igors по поводу вашей реплики насчёт моего предложения:

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

Вопрос to Igors -
Немного не понял кстати по поводу вашего шаблонного метода.
У вас получается то же самое, что и описано в моей функции, но вызывающееся для структуры у которой переопределён оператор ввода/вывода в поток?
Или же у вас описан шаблонный метод для структур, которые являются объединением с массивом?
Просто у вас там кратко написано *data, так что я путаюсь в догадках.


to sergek:

Ваш способ и есть тот камень преткновения. При изменении структуры, придётся переписывать функции send и receive.

Или я не уловил вашу систему и у вас сериализуются типы по их текстовому названию и вызывается соответствующий сериализатор?