Приветик всем)))
ПОМОГИТЕ ПЛИЗ!!! 
Нужно преобразовать double в __int64 без потери данных
Явным преобразованием типа: 



теряю данные....

может есть какая-нить сишная функция...???

а, еще проблемка, это нада сделать на Си...

Katshooter, 
Нужно преобразовать double в __int64 без потери данных
поясни глубинный смысл этой фразы.

))) сори, ну например double 12345672903000000+11E (в таком виде приходят данные), 
при при явном приведении получаем 12345672  (а ...903 округляются)

Katshooter, 
у тебя явно имеется талант к исчерпывающему и предельно понятному объяснению, однако. :gigi:

Кастуя телепатию, предполагаю, что требуется просто положить содержимое double в int64 побитово.


Хотя бред конечно. Но никакого другого способа всегда сохранить точное значение нет, fixed point тоже не катит.

Это сообщение отредактировал(а) Void - 15.12.2008, 21:09

спасибо) буду пробовать)))

по численному значению при таком способе сохранения переменные разных типов будут отличаться.. 
Т.е. использовать значения не приведя обратно к double просто бессмысленно.

Добавлено через 6 минут и 33 секунды

во первых int64 не сможет сохранить дробную часть числа, но даже если это не нужно то :
во вторых разброс значений целочисленной части double гораздо больше чем может вместить int64
следовательно решить задачу с вышеозвученным условием не реально.

насколько я понимаюб, человеку нужно сериализовать double
в int64 записать его реально - побитово

а вот как обстоят дела с разным представлением double числа на разных платформах (та даже на 2х exe-шках, собранных разными компиляторами), я не знаю. возможно double там представляется совсем по-разному, и тупое побитовое сохранение не приведет ни к чему хорошему

вот этот набросок каста
http://forum.vingrad.ru/index.php?showtopi...t&p=1721438
"предназначеный" для битового конвертирования с проверкой размера, и он более безопасен чем простое побитовое сохранение,
но код приспособленный под одну платформу не будет компилиться на другой. 
К  тому же его в той же теме и заругали, поэтому желаю 7 раз обдумать прежде чем использовать.

компилятор тут обычно не при чем
числа с ПТ хранятся в формате, пригодном для загрузки в FPU целевой платформы

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

во-первых d, а не df
во-вторых *((double*)&i)
а в третьих это UB насколько я понимаю

Да чего там, если размер одинаков, просто union - старый сишный метод. 

Ну и assert на равенство размеров, на всякий случай... 
И нет там никакого UB.

3.10/15

хотя не совсем понятно, что включает в себя "attempts to access" - но, ИМХО, и запись и чтение


Это сообщение отредактировал(а) J0ker - 17.12.2008, 20:40

Нет, в данном контексте это использование по назначению - т.е. в вычислениях (или в присваивании).
И потом, никто не говорит, что UB - это когда программа падает. Это просто значит, что результат получится неизвестно какой.
Скажем, целая -1, если ее таким образом преобразовать в double становится Not-a-number. И что там в вычислениях получится -  хто знает. 
Например, если сравнивать NAN с любым числом, то результат стабилен (не помню уже true или false), независимо от того, какое число и какое сравнение. С другой стороны - это не раз наблюдаемое мною поведение наверняка является свойством конкретного компилятора или может даже параметров компиляции (release-debug).

А писать-читать в память ты можешь что угодно - была бы память. Это ведь по сути ничем не отличается от memcpy, как предложил Void, только запись яснее (на мой взгляд).  Reinterpret_cast биты не портит... Т.е. если ты запихиваешь, скажем float в LPARAM, чтобы послать сообщение, а потом его оттуда извлекаешь обратной операцией, то все совершенно нормально и легально.