Russian Qt Forum

Добрый день
 решил прикрутить  сериализацию в приложение QT
мне это необходимо для сохранения класса настроек приложения в БД в бинарном виде.
чтоб не мучаться решил использовать в классе только STL + BOOST
испугался что QT типы не сериализуются.
Использовал как основу данны пример
http://rsdn.ru/forum/cpp/2545626.1.aspx

serialize выполняеться хорошо,
пытаюсь селать deserialize:



ничего не выходит, компилируеться все нормально но после этой строчки





в stream должен быть буффер device но его там нету почему то, stream инициализируеться но в нем находить левая информация такого типа 'НННННННННННННННННННННННННННН'...

подскажите пожалуйста

Немножко не на вопорс, но буквально вчера проскакивала тема серилизации тут :) Сериализация в Qt через использование MetaObject (http://habrahabr.ru/blogs/qt_software/83374/). Читать рекомендуется вместе с камментами :)

этот метод мне не нравиться ,пробовал уже заморачиваться c QDataStream и , у Boost все красиво и просто, и главное что уже готова, просто мне не нужно скидывать дамп объекта в файл а нужно в базу его писать. можно конечно сделать по грубому запсал в файл считал из него но больно уж не красиво охото по человечески тем более что сериализация работает , а не работает только в обратную сторону

Метод сериализации рассмотренный на ХАБРе имеет недостаток - надо все классы кот. требуется сериализовать наследовать от QObject - а для таких простых вещей как vector3d (маленький класс для 3D графики - это уже будет накладно). Мне кажется с QDataStream идея вернее...

Сори за оффтоп....

Ну уж через потоки БУСТа они ведь точно не сериализуюся?

Вы конечно же обратили внимание что многие Qt классы имеют non-members для записи / чтение в QDataStream (в документации это в разделе с конкретным классом а не в разделе QDataStream)

Я могу ошибаться но мне кажется  STL + BOOST не должны требоваться как раз если нужно сохранять набор Qt классов
1) Берем QBuffer (наследник QIODevice - как раз то что нужно чтобы не писать в файл в вашем случае)
2) Создаем на базе него QDataStream
3) Все в него пишем (как упомянул выше большинство Qt классов как раз сериализуюся)
4) Сохраняем в БД в блоб поле представляя QBuffer как QByteArray (QByteArray &   buffer ())
Вроде и все

Может поможет http://habrahabr.ru/blogs/qt_software/83374/

похоже не поможет ссылку давали вторым ответом

paxerus, спасибо поржал :D
да будет вам известно, что в бусте есть нормальный путь для сериализации.
со стандартными контейнерами все очень просто реализуется.
но для Qt, наверное геморно получится.

и что же вы смешного нашли спрашивается ,видимо вы не внимательно читали. куда уж стандартнее чем boos::serialize спрашиваеться???

Мне требуеться сохранить не стандартные QT класс а свой.
сериализация у меня готова(3 й раз переделывать из booыt обратно к QT уже не хочеться), я лишь прошу помочь сделать так чтоб мне не пришлось писать в файл, и помоч разобраться в примере,почему он не доконца работает
через boost, Qt типы я так понимаю тоже не сериализуються так как тут все наследованно и нужно тащить за собой кучу предков, а по умолчанию он вроде как ток указатели на них сохранит и все.
для моих целей (для хранения настроек системы) класса с использование STL и boost вполне достаточно, я там использую ptr_container -ы для хранения настроек,и все это красиво (еслиб еще работало до конца) сериализую

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

Убила эта фраза уже после того как указали где смотреть... Qt классы сериализуются по крайней мере большинство из них. Не удивляйтесь что на форуме Qt вам предлагают все таки использовать сериализацию Qt а не Boost. По личному опыту скажу что работать с контейнерами Qt гораздо удобнее чем с контейнерами STL.

Сериализовать указатели - это вообще какой-то бред! И что я по вашему в сеть передаю указатели на экземпляры класса на другой машине?????

Наследование также не имеет отношения к сериализации Qt. Механизм наследования использовался по приведенной ссылке - человек хотел универсальный способ - чтобы его "НОВЫЙ" класс сериализовался не делая для этого ничего - поэтому он оттолкнулся от QObject и его Q_PROPERTY. Эта схема не является 100% удобной и не везде ее можно использовать (хотя для чего -то очень даже подойдет).

В Qt сериализация происходит создание non-memeber членов класса перекрывающие операторы << и >> для записи в QDataStream. Но для большинства классов Qt они уже перекрыты! И поэтому они СЕРИАЛИЗУЮТСЯ - достаточно почитать доку уже наконец...

Кроме того для сохранения настроек программы в БД можно еще использовать QSettings определив для него процедуры чтения/записи в БД...

И QBuffer никто не отменял...

По поводу Boost - 90% что вы где то также не дочитали документацию и не вызываете какую-нибудь ф-ю чтения после объявления потока - но это вам быстрее подскажут на форуме Boost-а вероятно а не на форуме Qt...

спасибо за разъяснения

Почему-то про Q_GADGET все забыли, не обязательно наследоваться от QObject'a.

либо вы фанат Qt, либо никогда толком не работали с STL ;)

замечу, что STL, потому и "Standard Template Library". а стандарт утверждают не глупцы, прошу заметить. и существует он поболее чем Qt. и очень интенсивно развивается, особенно в последнее время. и boost переходит в новый стандарт, почти полностью. поэтому, STL и boost, это наиправельнейщий подход к программированию на с++.
...ах да, быдлокодинг...как же без этого :D

Стандарт и удобство это разные вещи! cstring тоже стандарт но по сравнению с QString гораздо менее удобен в использовании.

При чем тут глупцы? При чем тут сколько он существует?

Что ты тогда делаешь на этом форуме - используй только STL и куски BOOST-а перешедшие в стандарт.

особенно удобство STL проявляется при описании типа итератора - до сих пор еще не утвержден тип "AUTO" который позволит не писать огромной длины строки в коде.

P.S.: А про свой быдлокодинг ты мне не рассказывай у меня с этим все в порядке.

break
не думаю что вы компетентны оспаривать мою позицию/мнение. вам подучиться нужно. позже возвращайтесь ;D
особенно после этого:
несчастный, отсталый человечеГ ;D

это кто? :o

...

про строки имел ввиду std::string

пи...ть ума большого не надо - пока вижу только слова

ох ох ох уже боюсь
И где же приведенный мною код можно назвать быдлокодом? А то опять слова без подтверждения...

Поясни в чем его отсталость заключается? Я тоже считаю, что if(mymap.contain(key)) намного короче и удобнее, чем декларация итератора, вызов find с последующей проверкой на равенстов map.end().