Is storing $1.05 really that much simpler than storing something as 105? Use a long to store money, pretty easy.

If you store things in a hypothetical subsidiary unit, you end up with plenty of corner cases.

1. You might need a different number of "implied decimals". Two decimals is enough for many currencies, but some are three, quite a few are zero, and a few are a janky 1-decimal model. And that doesn't even go near, say, pre-1971 GBP structures.

You'll have to put scaling logic on every interface with the outside world.

2. Even if you do it perfectly, it's going to change. For example, the subsidiary unit on the Icelandic Krona is being removed in a lot of financial APIs right now. You can either change your records, or change your scaling logic, but you've now got an inflection point where you can't reason about the behaviour before the changeover from the current code.

What you need is a decimal type, where you can have 6.33 dollars, 2.167 dinars, or 500 won, and have them all retain fidelity. Sadly, few popular languages provide it.

I might or might not have stories about fix numerical types underflowing.

Not that fix nums are wrong, but they are far from safe.

Storing is one thing, computation is another :-)

Is computing with doubles faster than with longs or something?

Bond prices are quoted in 32nds (or 256ths) of a dollar. How am I storing that?

Still in a long, you can represent micro "cents" (e.g. 1,000,000 = 1 unit of the currencies smallest unit, for USD thats cents). It's just a matter of scaling things up or down to the level of granularity that you require.