Тут вопрос такой: есть ли наследование в этих структурах, и поля-ссылки на другие структуры, в частности ссылка на базовый тип, когда фактически там может быть и производный объект?

Не все в восторге от буста, но можно смотреть в таком разрезе, что люди там таки довольно много думали над проблемами и нашли не самые плохие способы их решения. А зачастую и самые лучшие в контексте поставленной задачи. Оператор &, шаблоны и макросы там не от хорошей жизни используют. Кстати, из-за обилия макросов мне этот буст и не нравится. Но Вы, когда будете развивать свой метод по объединению чтения/записи, верите или нет, наверняка придете к тому, что сейчас есть в бусте . А сейчас там есть определение перечня полей, подлежащих сериализации. И ничего лишнего в самих структурах. Всем остальным занимаются отдельные сериализаторы, с помощью которых хоть в QDataStream, хоть в XML, хоть куда можно сохранять. Т.е. в структуру добавить что-нить типа:

C
friend class boost::serialization::access;
template<class Archive>
void serialize(Archive & ar, const unsigned int version)
{
  ar & degrees;
  ar & minutes;
  ar & seconds;
}

и не надо больше никаких методов по вводу/выводу писать в каждой структуре. Вы же к этому и стремились: один раз описать поля и больше с ними не возиться .

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

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

1. Если много простых, несвязанных между собой структур, да большинство из которых нельзя модифицировать, то надо смотреть в сторону способа как в QDataStream.
2. Все структуры ваши и можете делать с ними все, что угодно, то брать буст или сделать аналогично.
3. Как п. 2, структуры разрозненные, но есть возможность добавить им всем общего предка, то сравнить способ буста и способ sergek.
4. Классы хорошо организованы в иерархии, довольно громоздкие, в некоторых случаях требуют индивидуальной обработки полей и есть возможность добавить общего предка, то можно попробовать слепить такого странного монстра XMLContentReader/XMLContentWriter.

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

А с шаблонами лучше разобраться, штука очень мощная, может сильно уменьшить объем написания кода. Правда мозги при этом свернутся .

Да, можно Mode сделать параметром шаблона, а не функции (тогда шаблоны Igors будут немного по другому выглядеть). При этом Mode должен быть известен в compile-time, что накладывает некоторые ограничения. В частности смотреть, что будет при наследовании, полях-ссылках на другие структуры и т.п.

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

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

Для определенных задач, когда клиент и сервер обменивается одинаковыми структурами в обе стороны, такой вариант может облегчить жизнь. Для других задач надо иметь в виду такой момент: если клиент отправляет серверу одну структуру типа request, а сервер в ответ другую типа response (и наоборот не будет), то при таком подходе этот вариант не самый лучший. Да, он в два раза уменьшит исходный код сериализации, но и в два раза увеличит конечный (скомпилированный) . Потому что клиенту не нужен read(request) и write(response), а серверу не нужен read(response) и write(request). В этом же варианте при любом значении mode скомпилируется код на чтение и на запись сразу, хоть это и не всем нужно.

Вариант sergek, конечно, хорош, но общий предок - это не совсем честно . С общим предком много чего можно сделать интересного. Можно взять общего предка QObject и практически бед не знать с его metaObject. Правда туда стороннюю произвольную структуру не воткнешь, и вернемся к тому, с чего начали.

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

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

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

Ручками, ручками . А если ручками лень, то написать парсер, который по исходникам сгенерит сериализаторы. Которые потом все равно придется ручками править .

Если применительно к структурам struct, то, похоже, все печально - к каждому полю придется обращаться отдельно. Махинации с памятью чреваты, как отметил Верес.

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

В boost'е тоже какие-то сериализаторы встречались.

Тут мы, наверное, по разному понимаем, что в контейнере может находится . В моем варианте в одном контейнере или много элементов одного типа (хоть несколько тысяч), или достаточно малое количество разных, причем заранее известно, в какой позиции какой тип находится. Можно, конечно, и тысячу разнотипных объектов в один контейнер засунуть, но это архитектурно другая задача будет. Это больше похоже на метод QObject::findChildren, который возвращает список объектов определенного типа, по которому потом можно пройти итератором. Правда пока он этот список создаст, он все тысячи объектов и промолотит .

Да, на первый взгляд выглядит заморочено, но если разобраться, то не все так страшно . Базовые классы CompositeContainer и CompositeItem довольно простые, все преобразования типов ложатся на плечи CompositeAdapter. Он и доступ к методам контейнера с конкретным типом элемента предоставит, и итератор подходящий создаст. Дополнительная прослойка, конечно, но, возможно, это не самое худшее из зол .

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

Это возможно для некоторого класса задач. Но я писал эту библиотеку специально для использования в Qt, а не общую реализацию для любых классов. Общую реализацию быстрее, красивше и лучше, наверняка, можно сделать с помощью Boost, там вроде достаточно возможностей для этого. Я такой вариант рассматривал, но решил не привязываться к Boost'у, да и стиль классов Qt мне нравится намного больше. А если в Qt не унаследоваться от QObject, то могут закидать камнями, типа: "И как мне теперь сигналы подключать? А metaObject() где?". В общем, я не рискнул .

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

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

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

Хотел сделать такую возможность, и даже пробовал. Очень тяжко это шло, много проблем возникало, поэтому пока остановился на QPointer в хранилище.

С этим согласен, каждый должен заниматься своим делом: контейнер хранить, сортировщик сортировать и т.п.

Тут возможна моя недоработка. По-хорошему, надо провести ревизию кода на предмет этого. Наверняка там много где еще можно const добавить.

Это все правильно, и надо еще хорошо подумать, как лучше клонирование организовать. Такой способ я ввел на самом раннем этапе, "чтоб был", потому что реальную его работу можно будет проверить на более позднем этапе, когда будет много вариантов деревьев для тестирования. Если честно, клонированием больших деревьев еще не занимался. Вопрос непростой, требует размышлений и тестирования. К особенностям некопирования QObject добавляются особенности компоновщика. Например, в одном контейнере может находиться ссылка на элемент в другом контейнере, и при ее копировании могут возникнуть сложности.

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

Это все неправильно. Если надо отображать таблицу без особых изысков, то лучше наследоваться от QAbstractTableModel и
Как "implement rowCount(), columnCount(), and data()" смотрите в примерах и внимательнее изучите "Model/View Programming", это в справке Qt есть.

Если коротко, то числа можно вывести как-то так:

Да, произвольный объект в контейнер вставить нельзя, для создания иерархии своих классов нужен определенный предок. Для листовых элементов это CompositeItem, для контейнеров - CompositeContainer. Например, AbstractSheet <- BookSheet, AbstractSheetCollection <- BookSheetCollection. Помимо общего предка, необходимо добавлять некоторые типы/методы, для контейнера минимум как в HomoCompositeContainer. Хотел уйти это этой копи-пасты, но, похоже, никуда от нее не денешься, можно только постараться свести ее к унифицированному виду.

Кроме последовательной индексации элементов в контейнере можно еще использовать ассоциативную. Так сделано в классах AbstractStringCatalog <- GenreCatalog, чтобы к элементу обращаться, например, таким способом:

Выше были описаны гомогенные контейнеры, в которых содержатся элементы одинакового типа. Но иногда возникает потребность хранить в одном контейнере элементы разного типа. В классе магазина BookShop хранятся разные полки: BookShelf, NewspaperShelf и MagazineShelf. Обращаться к ним можно с помощью таких конструкций:
Может не самый удачный способ, но лучше я пока не придумал .

Основная цель - чтобы было удобно пользоваться деревом объектов в "повседневном" коде, с минимумом лишних телодвижений. Доступ к объектам и методам через метаобъектную модель я бы все же удобным не назвал, она служит для несколько иных целей. Например, в композитном контейнере CompositeContainer при добавлении элемента проверяется его тип, чтобы нельзя было вставить объект другого типа, который не подходит к конкретному контейнеру. Вряд ли это можно сделать стандартными средствами метаобъектной модели. И много всего подобного.

Кроме того, в базовые классы композитного контейнера добавлены возможности шаблона проектирования Visitor, которые позволяют добавлять "якобы виртуальные" методы к уже существующим классам без их модификации. Пример этого можно увидеть в классах XMLContentWriter, XMLContentReader. Там, кстати, и используются возможности метаобъектной модели. И в то же время, именно из-за нее пример получился не совсем наглядным . Надо будет его исправить.