1. ## Validating Monetary Input

the user needs to enter a monetary value only into the program with with no extraneous cents, for example, 56, 56.32 178654.44, but not 123.223 etc.

I'm reading the data input via the keyboard into a string and using the atof function to convert the string to a double. The problem i am stuck at is I have to know check the number to make sure it contains no more than 2 deciamal places. I was on the path to multiplying the number by 100 to convert it to only "cents", but i don't know how to check to see if there are any extranous values after the new decimal points.

Say the input was 134.578
multiplying by 100 would give 13457.8 the problem now is how can I (efficiently) check to see that there is a 8 after the . ?

2. you already have it as a string so why not just find the period and get the length of the string that follows it
Code:
std::string money = "123.4556";
// locate the period
int pos = money.find('.');

// extract everything following the period
if(pos > 0)
{
money = money.substr(pos+1);
// get number of places after decimal point
int digits = money.length();
if(digits > 2)
{
cout << "Error" << endl;
}
}

3. Dragon, since his input allows for 56 (no decimal point) you might want to check for string::npos.
 ... maybe not, got to checking because I didn't think npos was guaranteed to be -1, but maybe it is, at least i can't find anything to the contrary.
Say the input was 134.578
multiplying by 100 would give 13457.8 the problem now is how can I (efficiently) check to see that there is a 8 after the . ?
Do you want to give error or just truncate the 8? if truncate then just cast to int after you multiply by 100 and divide by 100.00
Code:
double value = 134.578;
value = ((int)(value*100)/100.00);

4. >>Dragon, since his input allows for 56 (no decimal point) you might want to check for string::npos

The code I posted already checks for absence of a decimal point. pos is a signed int, and find() will return npos (-1 when typecast to signed int) if decimal not found.

I think string::npos is an unsigned int, so it will never be -1. But I use signed int because (1) I know the length of my strings will ALWAYS fit into a 32-bit signed int. (2) easier for me to use, and (3) the compiler always screemed at me when I tried to use npos (I prograly did it wrong!).

5. Originally Posted by Ancient Dragon

The code I posted already checks for absence of a decimal point. pos is a signed int, and find() will return npos (-1 when typecast to signed int) if decimal not found.

I think string::npos is an unsigned int, so it will never be -1. But I use signed int because (1) I know the length of my strings will ALWAYS fit into a 32-bit signed int. (2) easier for me to use, and (3) the compiler always screemed at me when I tried to use npos (I prograly did it wrong!).
Yea I saw your code checked and I editted my post, I knew that npos was unsigned, I know casting it to int will get you -1, however, my concern was portablility to 64 bit environments. Will that cast still work?

However, when I look at MSDN this is what they have:
Standard C++ Library Reference
basic_string::npos

An unsigned integral value initialized to –1 that indicates either "not found" or "all remaining characters" when a search function fails.

static const size_type npos = -1;
So that's when I went back and edited my reply.

6. >>my concern was portablility to 64 bit environments. Will that cast still work?

probably, if sizeof(int) == sizeof(string::npos), but I guess we will find out in not-too-distant future. Don't know how other 64-bit operating systems work, never used one.

7. So would the guaranteed-to-be-correct version be like this?
Code:
std::string::size_type pos = money.find('.');
if ( pos != std::string::npos ) { // ...

8. Originally Posted by Ancient Dragon
>>my concern was portablility to 64 bit environments. Will that cast still work?

probably, if sizeof(int) == sizeof(string::npos), but I guess we will find out in not-too-distant future. Don't know how other 64-bit operating systems work, never used one.
Sorry it was sort of a rhetorical question, showing my line of thought...the next passage II wrote was meant to show the answer.

So certainly it will work, because even if int goes to 64 bit, and unsigned is set to -1, which really sets it to some huge number, when cast to int it will be -1 again.