Здравствуйте, Alekzander, Вы писали:


A>А компиляторы, что ж... Всегда можно обойти эти проблемы через какой-нибудь __тип. Тем более, никто в здравом уме не будет писать в коде long double без тайпдефов из-за этих милых особенностей (если ты об этом).

Или нельзя найти какой-нибудь __тип. Потому что его нет. Найди мне, каким именем 10 байт long double в MSVC называется. А то я хранил его в массиве байт и ручками в double конвертил.


A>currency — sqlit'овский 8-байтовый INTEGER, который fixed point и в сто раз больше + код валюты. "Количество" считаем кодом валюты. (На уровне UI можно их или разделить, или придумать удачное название типа "Currency or quantity" ).

Некоторые акции торгуются по 0.000001 руб за штуку. Не ложится в твой currency. Но можно увеличить размер дробной части, до 6ти знаков, например. Правда, при этом лучше надеяться, что никогда не появится акций с ценой с большим количеством знаков. 0x7FFFFFFFFFFFFFFF/100000 = 92 233 720 368 547 руб. Ну, в принципе, для домашней бухгалтерии хватит. Только не пиши серьёзный софт


A>При попытках действий, которые выльются в преобразования, проверять, что currency и currency можно только складывать, вычитать и умножать при совместимом коде (складывать и вычитать строго одинаковые коды, а умножать только валюту на количество или количество на количество).

Для currency это в любом случае неплохо сделать, сделав currency отдельным типом.


A>В противном случае — выдавать предупреждение.

Если пользователю — то да, а так, в коде — только кидать исключение, ибо нефик


A>Что может пойти не так? (Кроме как всё, само собой).

Например, тебе понравится и ты решишь использовать свой fixed point ещё для чего-то. И забудешь, что при умножении надо будет удалять разряды справа. Или, в целом, произведение будет представимо в твоём fixed point, но в процессе умножения до нормализации разрядов произведение таки вылезает за допустимый в int64 диапазон.

Кстати, а дробная часть у тебя как, двоичная или десятичная будет?

В общем, удачки тебе с fixed point