привет.

сериализую массив 'long double'ов(исходный массив инициализирован целыми: 1,2,3,4,5,6) в текстовый архив. после десериализации, при выводе полученного массива на консоль, все отображается корректно.
проблема проявляется при сравнивании массивов с помощью memcmp(). при том, проблема проявилась только с текстовой сериализацей.

hex дамп исходного массива:

hex дамп полученного массива:


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

спасибо.


Это сообщение отредактировал(а) boostcoder - 27.5.2012, 21:31

long double случаем не 10ти байтовый? Может элементы выравнены на границу 4х байт и собственно отличаются мусором, которым забиваются байты выравнивания?

проверяю на x86_64. тут sizeof(long double) == 16.


эм.. может.
а как в этом убедится? как исправить?

  Скорее всего long double реально занимает 10 байт, потому что сопроцессор больше не умеет, а вот компилятор для оптимизации по скорости увеличил размер типа добавив лишних 6 байт, которые он не читает и не пишет и в сопроцессор они никак не попадают, поэтому могут содержать в себе что угодно. Проверить можно так. Сначала заполнить память заборчиком из бит 0xAA дает последовательность 01010101 , при помощи memset, а затем записать поверх заборчика полезные данные. После чего глянуть дамп. В каждом из блоков по 16 байт должны проглядываться фрагменты заборчика.

оно так на 32ух битной машине.
на 64ех битной  - равняется 16.
вот тому подтверждение: http://www.physics.uq.edu.au/people/foster...64_porting.html


таки вариант 
сейчас проверю...

Добавлено через 7 минут и 41 секунду

проверил еще и на венде. тоже 16.

это не  мешает быть полезными толъко 10 битам из 16..

хм..
без использования сериализации этот баг я немогу воспроизвести не на LWS, не на локальной машине  
код такой:

http://liveworkspace.org/code/3f721237a32a...fceb2a1d2434115

а вот если std::ostringstream и std::istringstream заменить на типы сериализатора/десериализатора - то ошибка восспроизведется.

если заменить на умножение, то получаем

http://liveworkspace.org/code/78c1ff19c351...bbd7fb2fd099b7f

Добавлено через 3 минуты и 12 секунд
если long double заменить на long, то получаем equal.
Наверное проблема в переводе плавающих чисел в строку и обратно. например, для числа 1,5 вполне может не оказаться двоичного представления, и ближайшее к нему будет равно 1,4(9), однако, при переводе его в строку, мы получим 1,5

жуть какая  


я тоже так думаю. вот только не знаю. на сколько такое поведение правильно..

 а чем десериализируете?

P.S. если вопрос о том могут ли равные значения бытьпредставлены разным набором битов, то ответ : могут 

исправленный код: http://liveworkspace.org/code/d57ddd3da320...88591407d374eac

Добавлено через 1 минуту и 13 секунд

этим.

для плавающих законно 

значит тест на сравнение байтового массива для таких типов некорректен?

хммм. а ведь проблема именно в long double.
c float и с double - всё в порядке.
http://liveworkspace.org/code/d85ee8ad014c...4c3cfac76e72602
значит это

не совсем верно

выходит так..
так может вовсе запретить использование 'long double' ? или оставить на страх и риск юзеров?