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

[Igors]

А я предлагаю добавить класс:

Тут согласен, смысл есть

[ViTech]

Какой "каждой структуре" Речь шла о полиморфных классах уже имеющих общую базу.

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

[Old]

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

Да. Вы заказываете у человека готовый код и согласовываете использование шаблонов. Человек вам делает этот код на шаблонах.
А когда вы хотите сами в нем что-то изменить  оказывается, что вы в этом ничего не понимаете и сделать ничего не можете.
После этого вы обвиняете всех кроме себя. Учитесь или не заказываете такой код.

А зачем Вы навесили уже 4 класса?

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

Зачем тащить QDataStream (и каждый такой stream) если мы хотим от него только операторы?

Мы хотим иметь архивы, которые позволяют сериализоваться в разные форматы (бинарный, текстовый, xml, json, ...)
Вот для примера я привел сериализацию в бинарный формат с использованием QDataStream?

Все в 1 хедере. Чего не хватает?

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

Ну значит QDataStream дурной тон - получает в конструкторе указатель на QIODevice

Да.

Но не член точно  

Комплексы?
Конечно лучше создавать объект на куче руками, а потом героически не забывать его удалить. Это же круто.
Но это круто только в школьных проектах.

[Igors]

Учитесь или не заказываете такой код.

Ролью учителя лучше не увлекаться  

Это называется иерархия классов. В дальнейшем, при развитии проекта, они наполнятся содержимым.
...
Мы хотим иметь архивы, которые позволяют сериализоваться в разные форматы (бинарный, текстовый, xml, json, ...) Вот для примера я привел сериализацию в бинарный формат с использованием QDataStream?

А какой ф-ционал Вы хотите поместить напр в qds_iarchive? Зачем нужен класс который никакой смысловой нагрузки не несет? Все делает QDataStream (или др базовый stream), archive просто обертка. Хотите разные форматы - ну и создавайте "инстансы". Почему не потемплейтить если это к месту?

Конечно лучше создавать объект на куче руками, а потом героически не забывать его удалить. Это же круто.
Но это круто только в школьных проектах.

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

[Old]

Ролью учителя лучше не увлекаться  

А я никого не учу.
Перечитайте сообщение - там о другом.

А какой ф-ционал Вы хотите поместить напр в qds_iarchive?

Все. Здесь все делает бэкэнд QDataStream, а вот если я захочу в качестве бэкэнда использовать QDomDocument для сериализации в xml, то придется добавлять.

Почему не потемплейтить если это к месту?

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

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

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

[Igors]

Ага-ага, а через пол года - захотел, а еще через пол года понял что течет, а еще через пол года переделок все починил. Перелопатив пол проекта.

Ну бывает и так - и это нормально, если не слишком часто. Но почему Вы решили что членство "есть правильно"? Только потому что "кто-то так сказал/написал?" Я замечал что именно вещи "принимаемые без доказательств" ведут к самым тяжелым ошибкам и переделкам.

Ну ладно, то все "цветочки". А вот как сохранять указатели/ссылки на объекты если сам сериализуемый объект их не создает и не удаляет? Что Вы об этом думаете?

[Igors]

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

Пример: посидели с друзьями, приняли пару литров для оживления беседы. Не вижу в этом ничего плохого. А вот если каждый день спозаранку пьян - разница есть?  То же и здесь - открываете, а там аж кишит, все на темплейтах, живого места просто нету. Чему же это все посвящено? После неск дней "вникания" - да ничему путному, заигрался в общность, вот и все. Словом - злоупотребляют     

[Old]

Но почему Вы решили что членство "есть правильно"? Только потому что "кто-то так сказал/написал?"

Про кого вы все время говорите? Кто сказал/написал? Скажите имя этого вашего врага.
Я пишу на C++ с 91 года, у меня практически нет авторитетов в этом вопросе. Хотя я не считаю себя гуру c++.

Я замечал что именно вещи "принимаемые без доказательств" ведут к самым тяжелым ошибкам и переделкам.

Точно. Вот вы и не можете мне привести этих доказательств. Хотя пытаетесь учить: "Члену нет". Хотя никаких причин нет и быть не может.

А вот как сохранять указатели/ссылки на объекты если сам сериализуемый объект их не создает и не удаляет?

Чуть позже напишу.

[Igors]

Точно. Вот вы и не можете мне привести этих доказательств. Хотя пытаетесь учить: "Члену нет".

Неправда, я таким жестокостям с членом не учил! . Ваше утверждение "голый указатель = плохо" имеет никак не больше доводов. Если QDataStream использует порочный (на Ваш взгляд) подход, то где же те грабли на которые (якобы) все должны наступать? Почему я о них никогда не слышал?

Я исходил из простых соображений. Если archive - обертка, то чего ради он должен брать на себя конструктор/деструктор базового stream? Почему я не могу зарядить просто базовый, а должен объявлять archive? Что если я захочу записать в тот же файл что-то вне рамок сериализации (напр TOC) ?

[Old]

Неправда, я таким жестокостям с членом не учил! .

Оно для вас было сомнительно и поэтому вы заменили его указателем.

Ваше утверждение "голый указатель = плохо" имеет никак не больше доводов.

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

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

Потому что в С++ есть ссылки, которые для этого подходят куда лучше.

Я исходил из простых соображений. Если archive - обертка, то чего ради он должен брать на себя конструктор/деструктор базового stream?

Почему обертка, это полноценный класс? Поток это поток, архив это архив. Не надо их сравнивать.

[Bepec]

Не соглашусь по умным указателям.

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

Другой вопрос, что это зависит от требований. Пять тысяч голых и пять тысяч умных это ООООЧЕЕНЬ большая разница. Удобная, хорошая, но разница.

[Old]

Другой вопрос, что это зависит от требований. Пять тысяч голых и пять тысяч умных это ООООЧЕЕНЬ большая разница. Удобная, хорошая, но разница.

Ох уж эти мифы и легенды...

[Old]

А вот как сохранять указатели/ссылки на объекты если сам сериализуемый объект их не создает и не удаляет?

Необходимо ввести уникальные идентификаторы объектов.
При сохранении, вместо указателя сохранять его идентификатор, а при чтении получать по идентификатору указатель на объект.

[ViTech]

При сохранении, вместо указателя сохранять его идентификатор, а при чтении получать по идентификатору указатель на объект.

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

[Igors]

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

Есть простой но ужасный довод что это не катит (4 латинских буквы)