C++ is bad: structs aren't the same as structs

Aug 20, 2009 20:38

Here's a fun little problem. Suppose you've got a system that makes use of the following struct:

struct User {
unsigned int user_id;
unsigned short access_level;
float account_balance; // stored as US dollars
}Your system is ridiculously well-tested, all the tests pass, everything works totally fine. I'll be so bold as to say it's (kinda) ( Read more... )

software engineering, software, cpp, cpp is bad

Leave a comment

Heh ISO floating point... anonymous October 15 2009, 06:34:35 UTC
As someone who has had this drilled into his head at Mudd, I'm not sure if I count as allowed to comment, but hey, I haven't seen any other responses so far.

It almost gives it away, but the reason you should never, ever store data that requires precision - like financial info - is because, well, ISO floating-point (i.e. the float or double types in C, C++, Java, Python, or pretty much any language) is imprecise by design. It's not possible to have arbitrary-precision numbers in POD like floats or doubles, because to have arbitrary precision you need an arbitrary number of bytes. Floating-point fudges this by storing a floating-point number encoded in fractional powers of two, which means that only numbers that are sums of integer powers of two (and fit within a certain range) are stored precisely, and such numbers are still limited by the number of available bytes. This also means that addition and multiplication aren't commutative, for obvious reasons.

Hence you could have an Office Space type problem, where adding $1 to someone's ( ... )

Reply

Re: Heh ISO floating point... big_bad_al October 15 2009, 08:14:19 UTC
Precisely! Using floating point numbers for money can land you in federal pound-me-in-the-ass prison. Addition and subtraction are noncommutative, which can lead to catastrophic cancellation (add a million dollars, add one cent, then subtract a million dollars, and you're left with nothing) and round-off errors when calculating exchange rates can cause similar woes (convert from dollars to euros to dollars again, and the balance is different). On top of that, doubles take up 64 bits in RAM but 80 bits in the FPU (see "extended precision"), which means that floating point comparison can be nondeterministic (depending on what else needs the FPU and what optimizations the compiler is trying, there isn't a good way to know how many bits of precision a given double will have ( ... )

Reply

Re: Heh ISO floating point... big_bad_al October 21 2009, 00:05:00 UTC
Wait, I think floating point operations are still commutative. However, they're not associative, which is what leads to the problems.

Reply

Re: Heh ISO floating point... anonymous October 23 2009, 12:19:25 UTC
You may be right about that. I believe ISO actually specifies commutativity for floating point ops, though associativity is definitely out.

Reply

Re: Heh ISO floating point... ahhunter January 6 2010, 09:40:22 UTC
I'm pretty sure floating point subtraction isn't commutative. :)

Reply


Leave a comment

Up