If I add the amount owed to the change, I get 99.99 which is fairly close to 100. I think this inaccuracy has something to do with 0.(9) = 1. In other words, the result it gave you is as close to 100 as can be represented by floating point.

So if you want to be exact with the till all the time, calculate in pennies using whole number types. You would still be dividing by denominations like you have in the original algorithm so it isn't that different.

No, but my teacher likes us using pass-by-reference variables (the double& part). I did the int * part (extra credit for using pointers/arrays, since we just started doing basic functions). I know int * coins is a pretty cheesy way of doing this (asking for some sort of a buffer overflow error) but for this program it isn't too dangerous.

Well, no.
But every C++ programmer chooses a style based upon his or her preferences.
Either the * or & binds to the name (typical C) or to the type (typical C++) or in the middle.
I just want you to be aware that there are 3 different styles and that you should choose one for yourself (not pick up one because your teacher said so).
Some people say it's good to be consistent and in some situations and jobs, you will have to be, so it might also be a good idea to stick to one style.
I like to put it next to the type to emphasis that it's part of the type (because int* var and float* var aren't the same type - something that int *var and float *var doesn't give the impression of).

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

As I've stated before, the change plus the amount owed comes to 99.99, a precision error on the part of the computer. I recommend reading about rounding errors and 0.(9) being equal to 1, both of which may be playing a role here in your program. Rounding errors occur because the range of a floating point must be expressed in a finite number of bits, so approximations of numbers like 100 or 0.2 or 0.1 will appear, to the detriment of your calculations. Most real-world financial software uses whole number math, in small denominations like pennies, to represent currency at some stage for these reasons.

So, you have my suggestion -- use integer math to get exact change every time. If you cannot do that (assignment restrictions?) then I recommend a comment stating what you have learned about the problem and your teacher will likely give you credit.

So... if I take the input as a string, find the '.' character and split everything from the left to an int called dollars, and the right to another int called change, it would work better? Since I'm only doing integer division...

I never fully understood what the answer was in the first place. How can you store a number like 56.78 in an int...

No I mean, really, what gave you that impression? You just started talking about it, and his code didn't have readability problems. You just assumed his teacher told him how to write it like that and reacted.

>> How can you store a number like 56.78 in an int
Convert the dollar amount into cents by multiplying 100. The result can then be truncated to a long.

No I mean, really, what gave you that impression? You just started talking about it, and his code didn't have readability problems. You just assumed his teacher told him how to write it like that and reacted.

Because
1) OP was using double &var
2) OP was using int * var

Two different styles, plus using the 1st, which according to some, should be uncommon in C++.

Originally Posted by Adak

io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.

Originally Posted by Salem

You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.