为什么应用程序通常不使用int内部表示货币值？ [英] Why don't applications typically use int to internally represent currency values?

问题描述

在C ++ / Java /中，为什么应用程序通常不使用整数数据类型（例如 int 或 long C＃）在内部表示货币值，而不是使用浮点数据类型（ float ， double ）例如Java的 BigDecimal ？

Why don't applications typically use an integer datatype (such as int or long in C++/Java/C#) to represent currency values internally, as opposed to using a floating-point datatype (float, double) or something like Java's BigDecimal?

例如，如果我正在编写Java应用程序，并且有一个变量，要表示美元的实际价值（不需要表示几美分的小数），我可以声明一个表示美分数量的 int 值。例如，值 $ 1.00将表示为100。这似乎是使用 double 的一个很好的选择（请参阅问题为什么不使用Double或Float表示货币？）或 BigDecimal （比简单的基本 int 重量更大的对象）。

For example, if I'm writing a Java application and I have a variable that I want to represent an actual value in U.S. dollars (no need to represent fractions of pennies), I could declare an int value that represents the number of cents. For example, a value of "$1.00" would be represented as 100. This seems like a good alternative to using a double (see question Why not use Double or Float to represent currency?) or a BigDecimal (which is a more heavyweight object than a simple primitive int).

显然，在向用户显示该整数值之前或在用户输入货币值时，该整数值需要转换（即从100转换为 $ 1或 $ 1.00），但这似乎并不明显比格式化 double 或 BigDecimal 来显示要麻烦得多。

Obviously, the integer value would need to be "translated" (i.e. from 100 to "$1" or "$1.00") before displaying it to a user, or upon user input of a currency value, but this doing this doesn't seem significantly more burdensome than formatting a double or a BigDecimal for display.

为什么在不需要表示美分（或其他货币类型的等值金额）的应用程序中，这种方法不是最佳实践？

Why isn't this approach a best practice among applications that don't need to represent fractions of cents (or the equivalent in other currency types)?

推荐答案

为什么应用程序通常不使用[

1. 它不能简单地编码。 $ 1.10转换为110¢。好的，但是什么时候需要计算税款（即1.10美元* 4.225％-密苏里州的税率得出0.046475美元）。要使所有钱都保持整数，您还必须将营业税转换为整数（4225），这需要将110¢进一步转换为11000000。然后，数学运算可以为11000000 * 4225/100000 =464750。这是这是一个问题，因为现在我们的价值不超过美分（分别为11000000和464750）。所有这些都是为了将​​钱存储为整数。

1. It does not make for simple coding. $1.10 translates to 110¢. Okay, but what about when you need to calculate tax (i.e $1.10 * 4.225% - Missouri's tax rate which results in $0.046475). To keep all money in whole numbers you'd have to also convert the sales tax to a whole number (4225), which would require converting 110¢ further to 11000000. The math then can be 11000000 * 4225 / 100000 = 464750. This is a problem as now we have values in fractions of cents (11000000 and 464750 respectively). All this for the sake of storing money as whole numbers.

因此，就本币而言，更易于思考和编码。在美国，这将以美元为单位，美分是小数部分（即1.10美元）。以110美分的编码方式不是很自然。使用以10为底的浮点数（例如Java的 BigDecimal 和.NET的 Decimal ）对于货币通常足够精确值（与 Float 和 Double 之类的以2为基的浮点数相比）。

Therefore, it's easier to think and code in terms of the native currency. In the United States, this would be in dollars with the cents being a decimal fraction (i.e. $1.10). Coding such in terms of 110¢ isn't as natural. Using base-10 floating point numbers (such as Java's BigDecimal, and .NET's Decimal) are usually precise enough for currency values (compared to base-2 floating point numbers like Float and Double).

为什么在不需要代表美分（或等值的其他货币）的应用程序中，这种方法不是最佳实践类型）？

我认为上面的数字1表示，要代表销售分数很难摆脱，至少在计算销售额时税-在业务应用程序中很常见。

I think number 1 above shows that it's hard to get away from needing to represent fractions of cents, at least when it comes to calculating sales tax - something common in business applications.

这篇关于为什么应用程序通常不使用int内部表示货币值？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！