Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > boost::serialization ? баг : фича

Автор: volatile 4.2.2011, 01:39

Сначала небольшой материал: Код #include "stdafx.h" #include <fstream> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <string> class test // Наш небольшой класс, который хранит имя и возраст. {     friend class boost::serialization::access;     template<class Archive>     void serialize(Archive & ar, const unsigned int version)     {         ar & name;         ar & age;     }     std::wstring name; // Имя     int age;           // Возраст public:     test () {;}     test (const std::wstring &n, int a) : name(n), age(a) {;}     bool operator==(const test& v) {return name==v.name && age==v.age;} // Это для стравнения }; BOOST_CLASS_TRACKING(test, boost::serialization::track_never); // Это чтоб ворингов не было int _tmain(int argc, _TCHAR* argv[]) {    test a(L"Алла Пугачёва", 60); // Наши данные, их будем сериализовать.    test b; // Сюда будем читать.        {  // Сериализуем в файл наши данные       std::ofstream ofs("name.txt", std::ios::out);       boost::archive::text_oarchive oa(ofs);       oa << a;    }    {  // Читаем наши данные из файла в другую переменную        std::ifstream ifs("name.txt", std::ios::in);       boost::archive::text_iarchive ia(ifs);       ia >> b;    }    //Проверяем на соответствие.    std::cout << (b==a ? "Good" : "Bad") ;    return 0; } Итак запускаем программку. Выводит: "Good". Хорошо!. Теперь вместо "Алла Пугачёва", вбиваем "Филипп Киркоров" Запускаем... и тут ... нас ждёт неожиданный эксцепшн "stream error"! Мы не поменяли ничего в программе, только данные изменились. Я долго не мог понять, почему?!! Оказывается дело в том что в юникодной кодировке, русская буква "К" имеет код 0x041A а байт с кодом 1A буст воспринимает за конец файла. Если бы не было дальнейшего вывода после имени, (а я специально для наглядности вывел здесь возраст), то и исключения бы не было, просто считалось бы "Филипп " и всё, без "Киркорова" и без ксцепшна.  Не знаю это баг, или фича. Скорее все-же баг. Потому-что, если буст не поддреживает юникод, то и тип wstring поддерживать не нужно. А вообще все работает нормально, с любым юникодным текстом, но только до тех пор, пока не встретится большая русская буква "К". Теперь буду работать с бинарным выводом. Прошу комментировать.

Автор: KaraKum 4.2.2011, 01:41

Ну все давно поняли что Киркоров нехороший человек. Вон даже boost об него спотыкается

Автор: kemiisto 4.2.2011, 01:52

Цитата(volatile @  3.2.2011,  23:39 ) Не знаю это баг, или фича. Скорее все-же баг.  Как ты смеешь, негодяй!? Это фича. Какие баги могут быть в величайшем творении человечества!? Да снизойдёт на тебя кара небесная, мерзавец! Цитата(volatile @  3.2.2011,  23:39 ) Прошу комментировать. Да тут, собственно, нечего комментировать. Приятного аппетита!

Автор: boostcoder 4.2.2011, 02:40

наверняка все же баг... но какой-то странный.. Цитата(volatile @  4.2.2011,  01:39 ) байт с кодом 1A буст воспринимает за конец файла. буст большой. о какой именно части буста вы говорите? зы в жизни не использовал юникод, и не очень понимаю для чего он. но раз, или два, использовал кириллицу, и на такой баг не напоролся.

Автор: KaraKum 4.2.2011, 02:45

Цитата(boostcoder @  4.2.2011,  03:40 ) о какой именно части буста вы говорите? Речь идёт о сериализации. http://stackoverflow.com/questions/3129419/c-iostreams-question похожая проблема - видимо это не совсем баг - нужно попробовать boost::archive::binary_archive вместо boost::archive::text_oarchive.

Автор: Alexeis 4.2.2011, 08:12

А я недавно также напоролся на баг именно с юникодом. Тоже анси все ок, а точка юникода смерть. Грешил на билдер, но сейчас подумал, что новый билдер содержит обновление буста....

Автор: xvr 4.2.2011, 13:38

Откройте выходной и входной файлы в бинарном режиме (в std::ofstream и std::ifstream добавить std::ios::binary) и не катите бочку на boost, он тут не пи чем

Автор: KaraKum 4.2.2011, 13:40

Цитата(xvr @  4.2.2011,  14:38 ) не катите бочку на boost А что мешало хвалёному бусту получить размер файла при его открытии для определения его окончания чтобы не напарываться вот на такие костыли??

Автор: xvr 4.2.2011, 13:49

Цитата(KaraKum @  4.2.2011,  13:40 ) А что мешало хвалёному бусту получить размер файла при его открытии для определения его окончания Вы удивитесь, но файл будет короче, чем ожидалось    Проблема не в boost'е, а в файловом потоке, который открыли в текстовой моде (она такая по умолчанию).  Вот тут: Код std::ofstream ofs("name.txt", std::ios::out); // и тут std::ifstream ifs("name.txt", std::ios::in); А так же в том, что туда попытались записать (а потом прочесть) байт 1A. И файловый поток обрезал по 1A содержимое, а не boost

Автор: KaraKum 4.2.2011, 13:51

Цитата(xvr @  4.2.2011,  14:49 ) Вы удивитесь, но файл будет короче, чем ожидалось Что?

Автор: xvr 4.2.2011, 14:27

Цитата(KaraKum @ 4.2.2011,  13:51) Цитата(xvr @  4.2.2011,  14:49 ) Вы удивитесь, но файл будет короче, чем ожидалось Что? Пример - Код #include <fstream> #include <iostream> #include <string> int main() {   {    std::ofstream ofs("name.txt", std::ios::out);    ofs<<"TestStrng" "\x1A" "eriuwiorwodjdkcdmncv"<<std::endl;   }   {    std::ifstream ifs("name.txt", std::ios::in);    while(ifs)     {      std::string s;      getline(ifs,s);      std::cout << s << std::endl;      std::cout << s.size() << std::endl;     }   }  return 0; } VS2008 Результат - Цитата TestStrng 9 0 Как видим хвост после 1A беследно исчез (хотя в файл 'name.txt' и записался, хотя был в праве обрезаться уже там)

Автор: KaraKum 4.2.2011, 14:44

Пример полный и понятный. Спасибо. Получается мы перекладываем вину с boost'а на std, что не освобождает boost от ответственности, которого можно привлечь за http://ru.wikipedia.org/wiki/Преступное_бездействие

Автор: boostcoder 4.2.2011, 14:48

я так понял, что в текстовом моде, код 1A, не является валидным.

Автор: KaraKum 4.2.2011, 14:53

Это буква "К" - что в ней невалидного? http://www.unicode.org/charts/PDF/U0400.pdf

Автор: xvr 4.2.2011, 14:54

Цитата(boostcoder @ 4.2.2011,  14:48) я так понял, что в текстовом моде, код 1A, не является валидным. Почему же, это вполне валидный признак конца файла   Ноги у этого 1A растут еще из CPM (была такая ОС, предшественник MSDOS). В CPM длинна файла определялась количеством блоков в нем (по 128 байт). Частичные блоки не поддерживались. Поэтому, что бы в текстах не было мусора в конце (до границы 128ми байтового блока), и был зарезервирован специальный код (1A), для обозначения конца данных в файле

Автор: KaraKum 4.2.2011, 15:18

А вот интересно - зачем нужен вообще этот символ? Ведь стандартная C библиотека позволяет определить размер файла: Код   // obtain file size:   fseek (pFile , 0 , SEEK_END);   lSize = ftell (pFile);   rewind (pFile); Почему бы std::ifstream не определить в конструкторе размер файла и не обрабатывать каждое чтение согласно этому размеру? Неужели это для совместимости с CPM?

Автор: xvr 4.2.2011, 16:33

Цитата(KaraKum @  4.2.2011,  15:18 ) А вот интересно - зачем нужен вообще этот символ? Ведь стандартная C библиотека позволяет определить размер файла: Его и ifstream определить может (через seekg/tellg), и правильно определяет, но не читает до конца - поток переходит в EOF состояние ДО достижения реального конца в файле. Кстати, со стандартной С библиотекой те же самые грабли - она тоже не станет читать дальше 1A (хоть размер и определит) Цитата(KaraKum @  4.2.2011,  15:18 ) Неужели это для совместимости с CPM? По сути - да

Автор: KaraKum 4.2.2011, 16:38

Цитата(xvr @ 4.2.2011,  17:33) Цитата(KaraKum @  4.2.2011,  15:18 ) Неужели это для совместимости с CPM? По сути - да   Ужас какой. И долго ещё нас будут преследовать эти окаменелости наших до-POSIX предков?

Автор: volatile 4.2.2011, 23:27

Да всё это понятно что это старая проблема, но буст громко заявляет что его сериализация будет считываться правильно на любых машинах, в том числе даже с обратным порядком байтов (Little endian) (Big endian) и т.д. и т.п. Это конечно к данной проблеме не относится напрямую, но разработчики могли бы учесть и этот момент и передавать байт 1A в текстовом виде (например что-то типа "%1A", как в адресной строке браузера, например). В любом случае, все эти библиотеки пишут люди далёкие от проблем локализации. Больше всего не приятно, что этот баг проявляется тихо и редко. Когда выложена такая маленькая программка, то все понятно, конечно. А если большой проект, и там где-то внутри, иногда, непонятно от чего вылетает непонятно что, долго придется ломать голову, и валить на неполадки в питании, микросхемы памяти, фазы луны...

Автор: mes 5.2.2011, 00:47

Цитата(volatile @  4.2.2011,  22:27 ) Да всё это понятно что это старая проблема, но буст громко заявляет что его сериализация будет считываться правильно на любых машинах, в том числе даже с обратным порядком байтов (Little endian) (Big endian) и т.д. и т.п. для бинарного потока данных, а не для текстового.. на последний есть свои правила и ограничения (и 0х1а не единственный в своем роде),  в следствии чего он просто не применим для подобных целей..

Автор: volatile 5.2.2011, 01:43

Но, тем не менее разработчики оказывается осведомлены об этом баге, и общеают в будущем исправиться, выводя код EOF ескейп-последовательностями: Цитата Pending issues ... •Its possible that std::string and std::wstring contain characters such as '\0' and -1 (EOF) which cannot be rendered in text and XML archives without an escape mechanism. Currently there is no such escape mechanism implemented.  Добавлено @ 01:53 Да, вот линк, где это написано. http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/release.html Так что не все так плохо, и когда-нибудь будет совсем хорошо.

Автор: xvr 5.2.2011, 16:41

Это как бы не баг, это фича   Программист должен понимать, что он делает. Если открыть на запись /dev/null и дать бусту он тоже туда все замечательно сериализует. Или boost должен это тоже отлавливать и писать куда нибудь в другое место?

Автор: boostcoder 5.2.2011, 16:44

Цитата(xvr @  5.2.2011,  16:41 ) Это как бы не баг, это фича не баг. но очень провоцирует.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)