Сначала небольшой материал:

Итак запускаем программку.
Выводит: "Good". Хорошо!.

Теперь вместо "Алла Пугачёва", вбиваем "Филипп Киркоров"
Запускаем... и тут ... нас ждёт неожиданный эксцепшн "stream error"!
Мы не поменяли ничего в программе, только данные изменились.
Я долго не мог понять, почему?!!

Оказывается дело в том что в юникодной кодировке, русская буква "К" имеет код 0x041A
а байт с кодом 1A буст воспринимает за конец файла.
Если бы не было дальнейшего вывода после имени, (а я специально для наглядности вывел здесь возраст),
то и исключения бы не было, просто считалось бы "Филипп " и всё, без "Киркорова" и без ксцепшна. 

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

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

Как ты смеешь, негодяй!? Это фича. Какие баги могут быть в величайшем творении человечества!? Да снизойдёт на тебя кара небесная, мерзавец!


Да тут, собственно, нечего комментировать.



Приятного аппетита!

Это сообщение отредактировал(а) kemiisto - 4.2.2011, 01:53

наверняка все же баг... но какой-то странный..


буст большой. о какой именно части буста вы говорите?


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

Речь идёт о сериализации.

Вот тут похожая проблема - видимо это не совсем баг - нужно попробовать boost::archive::binary_archive вместо boost::archive::text_oarchive.

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

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

А что мешало хвалёному бусту получить размер файла при его открытии для определения его окончания чтобы не напарываться вот на такие костыли??

Вы удивитесь, но файл будет короче, чем ожидалось   
Проблема не в boost'е, а в файловом потоке, который открыли в текстовой моде (она такая по умолчанию). 
Вот тут:

А так же в том, что туда попытались записать (а потом прочесть) байт 1A. И файловый поток обрезал по 1A содержимое, а не boost   

Что?

Пример -

VS2008

Результат -
Как видим хвост после 1A беследно исчез (хотя в файл 'name.txt' и записался, хотя был в праве обрезаться уже там)


Это сообщение отредактировал(а) xvr - 4.2.2011, 14:28

Пример полный и понятный. Спасибо.
Получается мы перекладываем вину с boost'а на std, что не освобождает boost от ответственности, которого можно привлечь за бездействие   

Это сообщение отредактировал(а) KaraKum - 4.2.2011, 14:44

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

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

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

А вот интересно - зачем нужен вообще этот символ? Ведь стандартная C библиотека позволяет определить размер файла:

Почему бы std::ifstream не определить в конструкторе размер файла и не обрабатывать каждое чтение согласно этому размеру?
Неужели это для совместимости с CPM?   

Это сообщение отредактировал(а) KaraKum - 4.2.2011, 15:19

Его и ifstream определить может (через seekg/tellg), и правильно определяет, но не читает до конца - поток переходит в EOF состояние ДО достижения реального конца в файле. Кстати, со стандартной С библиотекой те же самые грабли - она тоже не станет читать дальше 1A (хоть размер и определит)

По сути - да   

Ужас какой.
И долго ещё нас будут преследовать эти окаменелости наших до-POSIX предков?  

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

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

для бинарного потока данных, а не для текстового.. на последний есть свои правила и ограничения (и 0х1а не единственный в своем роде),  в следствии чего он просто не применим для подобных целей.. 


Это сообщение отредактировал(а) mes - 5.2.2011, 00:49

Но, тем не менее разработчики оказывается осведомлены об этом баге, и общеают в будущем исправиться, выводя код EOF ескейп-последовательностями:



Добавлено @ 01:53
Да, вот линк, где это написано.
http://www.boost.org/doc/libs/1_45_0/libs/...oc/release.html

Так что не все так плохо, и когда-нибудь будет совсем хорошо. 


Это сообщение отредактировал(а) volatile - 5.2.2011, 01:56

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

не баг. но очень провоцирует.