[scratt]

Can anyone tell me why reading this line of text from a file.....

10,400

..on a Mac using a file stream into a 'float' will get me what I expect... i.e. 10.0 in the float.

But if I try to do the same on a PC I get a wierd number in that float.

I am still able to read the '10' into a string using the same piece of code on the PC, but replacing my float with a string.. So I know I am reading from the right place in the file etc. etc.
But into a float not at all..

[PLEASE NOTE - I am very aware of the text file differences between a Mac and PC]

Is there something different about these basic C commands, or their implementation on a PC?
Or am I missing something really obvious?

Has my computer broken?

I can't believe I have not come accross this before.. and am sure I am doing something totally stupid!! But I don't care! I just want it to stop!

Thanks for any help..

[chucker]

Originally Posted by scratt [PLEASE NOTE - I am very aware of the text file differences between a Mac and PC]

So you are filtering out line endings, right?

[scratt]

Absolutely..

At the moment I am opening the file, and reading the very first few characters from it. I don't even get to a line ending, even if that was the problem!

As I said above I can get the '10' to go into a string, and print it out as '10'.

But if I change the string to a float, or an int I get a huge number.

I don't know how else to eliminate the problem.

This same code works on my Mac fine.

It's one single 'fin >> variable' line.

Make 'variable' a string and I get what's in the file..
Make 'variable' a float or and int and I don't get anything like 10.0!!!

I wondered for a while if windoze text files have some kind of header I didn't know about.. But evidently not, as the string read works..

So then I actually ported the code I use to make the text files accross to the PC and got it to make the files I am trying to read with this utility natively. The files look great, and I can load them and look at them.. The wierd thing is, as I am sure you are aware that the code to generate one of these text files, is almost identical to the code I am using to read them!! And yet one works fine.. but the single 'fin >> variable' line I am using in the problematic program does not!!

[spotcatbug]

iostream automatically deals with comma separated values for input?

Hmmm... maybe the Mac version hits the comma and stops (error), after having successfully read the first float, but the Windows version hits the comma and stops (error), without having read the first float (leaving it undefined).

Or maybe I'm not understanding the situation correctly.

[scratt]

Hmmmm... Interesting...

I have used this method on Macs for years.

fin >> value; // int, float, whatever..
fin >> char; // get the ','
fin >> nextvalue;

and so on..

Your suggestion has merit.. I will slap some error checking round it and see..

[scratt]

Hmm... Tried that..

Well it doesn't flag an error on the PC as far as I can tell..

Any other suggestions.. I think I am losing my mind!

[spotcatbug]

Try using a space instead of a comma. I know that may not meet your requirements, but just to see if that will work.

[scratt]

The problem is with the first number in the file.. At the moment the comma doesn't even come into it.. But I have tried as you suggest, and no dice..

What is actully happening is an error when I try to read.
I have found that now..
However, clearing the error does not help...

Reading the number into a string, does.
But reading it into a float makes the error occur!

I have been all over the web trying to find similar problems, but most are people sitting in an infinite loop trying to read and not checking for an error..

My code does not loop.. It runs straight through.

So, strange.... Grrrrrrrrrrr!

[spotcatbug]

I don't think there would be any issues with reading a text file on a Mac vs. a PC, except, as you mention, the line endings; however, just to eliminate the file altogether, have you tried reading the float from a strstream instead of a file stream?

[spotcatbug]

BTW, the first thing that popped into my head when I saw your original post was that many countries use commas as their decimal separator. In France, for example, people would probably expect "10,400" to read as a single float. That's why I fixated on the comma.

I don't know why I felt I should mention this, but there it is.

[scratt]

I have got around it now, but changing the way I read from the file..
I am reading strings and converting them...
But it seems a very arse about face way of doing it..

Thanks everyone for your input..
I am still curious, but must get on with this project for now.

If anyone stumbles across a similar problem in their travels please let me know.

[scratt]

Originally Posted by spotcatbug ...people would probably expect "10,400" to read as a single float. That's why I fixated on the comma. I don't know why I felt I should mention this, but there it is.

That's a very valid point...

I think I am going to change to binary files from now on..

[Enki]

Scratt,

C++ is basically retarded when it comes to reading things in using the Cin object. Also the specific implementations can have edge case compiler specific behaviors as long as they meet the basic standard and that's probably why the Apple version doesn't choke on 10,400 but the PC based version does.

I make my students build a Class library that reads in either strings or characters, does the error and format checking via roll you own methods and then use atoi/atof to turn a validated string into a number. There is also a slicker method that uses Class StringStream and you can use standard stream operators to do the conversions on the error checked strings.

Either way the strings will need to have the commas stripped, the basic libraries' standards accept decimal points as part of the number, but are not forced by the standard to accept commas, they are optional and compiler specific if the libraries properly handles them. This can be especially aggravating for regions that use commas rather than decimal points for floating point numbers.

[scratt]

Hi Enki,

Thanks for that.. Makes sense..

It's rather ironic that with all my bitching about windoze, that I end up getting bitten by a standards issue when going from Mac to PeeCee!

[Kickaha]

Er, make sure that the locale facet is set properly?

[scratt]

It is...

The problem is (on further investigation - and a nights sleep) that on the PeeCee it simply will not recognize the numbers and *will not* read them into a float if they have anything other then a space between them.

It does not read 10,400 as 10 thousand 400 hundred, as I think some people are thinking.. It simply sets the error bit and does not progress through the file.. and the float I am reading into keeps it's undefined value.

I had missed a commented out command when I told spotcatbug that putting spaces in did not work... This morning trying a file with all the ','s replaced by spaces, and a few other bits of jiggery pokey got it to work...

Basically I got bitten hard and wasted a few hours by assuming that a very quick and dirty method I use for utility programs (when developing other stuff more neatly) would work on any C++ flavour.. I was soooooooo wrong!

[Kickaha]

Ahhhh, I thought it was 10.400 vs. 10,400 formatting that was throwing it, but you're seeing it just plain barf when it hits the comma.

Not as smart as a Mac, no wireless. Lame.

[scratt]

Yup.. Pretty lame..

I tell you what though.. Visual Studio is pretty good in the 05 incarnation.
It is not disimilar to XCode, and pretty intuitive once you get into it.
It also runs really fast on Parallels, as does the graphic intensive code I have been working on.. I am super super impressed with Parallels.

The compilers on the PeeCee are much much stricter on formatting than on the Mac. It actually makes the Mac look very much like a stoner in terms of it's laid back approach to certain formatting and so on..

When I first tried to port this code I got hundreds of errors, and to be honest as I went through them they were all for things like 'ambiguous calls' to routines which are overloaded, or for places where the compiler wanted more brackets to be absolutely clear what order logic was being done in.. and even some places where it wanted a cast where the Mac had just got on with it and made it's own mind up about what I meant..

It was quite wierd.. Made me feel like I had turned up from being home schooled, only to get my ass kicked at college for being a sloppy hic.

[Enki]

VS2005 went a bit overboard on what falls into a Level3 warning. It seems to throw loss of precision errors even when implicitly casting to a higher precision format. Throwing a warning on implicitly promoting a declared float to a declared double is just stupid. VS2003 handled those in a more realistic manner. I'm going to guess a lot of the warnings and errors you came across are due to issues as innocuous as those. Things where they just don't trust their own compiler writers to parse it right.

I think MS did a lot of that to force their own internal folks to get more serious about writing explicitly tight code. But getting medieval on type promotions just seems a bit off in left field in the larger code security business. But that's where MS has been for ages.