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

M>x86-64 clang 13.0.0
M>x86-64 gcc 13.2
M>MSVC 2005
M>MSVC 2017
M>BCC 5.5 (да, древнее говно)

Ограничивающим фактором является, скорее, вот это: https://www.sqlite.org/datatype3.html

REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number.

Я так понял, другого double у них для нас нет ))

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

M>Я когда-то весело попрыгал по граблям, когда прибор выдавал двоичные данные и там был long double, у меня был MSVC, а прошивку прибора писали на бомановском 3.1

M>Помимо несовместимости разных компиляторов, ты решишь, что 640long double уже точно хватит всем, но это не так, в лучшем случае грабли вылезут чуть попозже, если long double на твоей платформе больше обычного double.

M>В общем, очень плохая идея. Хуже всех остальных. И таки да, для бабла ничего лучше LongNumber не придумали, а в условном калькуляторе это никак не повлияет на производительность, а от кучи гемора тебя он избавит. Я бы его использовал и не парился

Послушав всех, я склоняюсь к двум типам: number и currency (название условно).

number как в JS'е (т.е. sqlit'овский 8-байтовый REAL), но с принудительным выводом на разряд меньше (если форматирование не задано) и с эпсилоновской реализацией ==.

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

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

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

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

M>x86-64 clang 13.0.0
M>x86-64 gcc 13.2
M>MSVC 2005
M>MSVC 2017
M>BCC 5.5 (да, древнее говно)

Ограничивающим фактором является, скорее, вот это: https://www.sqlite.org/datatype3.html

REAL. The value is a floating point value, stored as an 8-byte IEEE floating point number.

Я так понял, другого double у них для нас нет ))

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

M>Я когда-то весело попрыгал по граблям, когда прибор выдавал двоичные данные и там был long double, у меня был MSVC, а прошивку прибора писали на бомановском 3.1

M>Помимо несовместимости разных компиляторов, ты решишь, что 640long double уже точно хватит всем, но это не так, в лучшем случае грабли вылезут чуть попозже, если long double на твоей платформе больше обычного double.

M>В общем, очень плохая идея. Хуже всех остальных. И таки да, для бабла ничего лучше LongNumber не придумали, а в условном калькуляторе это никак не повлияет на производительность, а от кучи гемора тебя он избавит. Я бы его использовал и не парился

Послушав всех, я склоняюсь к двум типам: number и currency (название условно).

number как в JS'е (т.е. sqlit'овский 8-байтовый REAL), но с принудительным выводом на разряд меньше (если форматирование не задано) и с эпсилоновской реализацией ==.

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

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

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