«

a kinda newbie here.
I've done a simple little program that reads a text file and counts the number of lines and words.
I had a heck of a time getting it to count properly when I finally discovered the problem was not my coding, but the istream altering the incoming text.
What I was doing was checking each incoming character (seekg) and comparing it to a 'h0a' . What I found was that text files end their lines with a '0d' (CR) and a '0a' (line feed). However, it was reading them off the istream as both being '0a'. It had changed the CR.
My questions are, Is there any other little istream quirks like this I should be aware of? And is there some way to set the stream to not alter what is read?
TIA
-doh

* dohboy:
> a kinda newbie here.
> I've done a simple little program that reads a text file and counts the number
> of lines and words.
> I had a heck of a time getting it to count properly when I finally discovered
> the problem was not my coding, but the istream altering the incoming text.
> What I was doing was checking each incoming character (seekg) and comparing it
> to a 'h0a' . What I found was that text files end their lines with a '0d' (CR)
> and a '0a' (line feed). However, it was reading them off the istream as both
> being '0a'. It had changed the CR.
> My questions are, Is there any other little istream quirks like this I should be
> aware of? And is there some way to set the stream to not alter what is read?

By default text streams translate the OS convention for newline into
'\n' on input, and vice versa, translate '\n' to OS convention on output.

Since you're counting lines it's probably best to work with that feature
instead of trying to turn it off.


Cheers, & hth.,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

dohboy wrote:
> a kinda newbie here.
> I've done a simple little program that reads a text file and counts the number of lines and words.
> I had a heck of a time getting it to count properly when I finally discovered the problem was not my coding, but the istream altering the incoming text.
> What I was doing was checking each incoming character (seekg) and comparing it to a 'h0a' . What I found was that text files end their lines with a '0d' (CR) and a '0a' (line feed). However, it was reading them off the istream as both being '0a'. It had changed the CR.
> My questions are, Is there any other little istream quirks like this I should be aware of? And is there some way to set the stream to not alter what is read?

It'd more of a normalisation than a quirk. It saves the programmer from
tedious platform specific conversion code.

I guess another is the use of the eof flag to hide platform specific
file endings.

--
Ian Collins.

Hi,

Didn't test the following code. But you might want to use something like
this

#include <fstream>
#include <string>
#include <algorithm>

using namespace std;

ifstream Input( Filename.c_str(), ios_base::binary );

// test if open!
//So files are read the same on whatever system then you might want to get
rid of any carriage returns with something like
string Line;
while( getline( Input, Line ) )
{
Line.erase( remove_if( Line.begin(), Line.end(), bind2nd(
equal_to<char>(), (char)13) ), Line.end() );

// From here on Line is the same on unix and ms-windows
}


Regards, Ron AF Greve

http://www.InformationSuperHighway.eu

"dohboy" <dohboy@*******s.com> wrote in message
news:...
>a kinda newbie here.
> I've done a simple little program that reads a text file and counts the
> number of lines and words.
> I had a heck of a time getting it to count properly when I finally
> discovered the problem was not my coding, but the istream altering the
> incoming text.
> What I was doing was checking each incoming character (seekg) and
> comparing it to a 'h0a' . What I found was that text files end their lines
> with a '0d' (CR) and a '0a' (line feed). However, it was reading them off
> the istream as both being '0a'. It had changed the CR.
> My questions are, Is there any other little istream quirks like this I
> should be aware of? And is there some way to set the stream to not alter
> what is read?
> TIA
> -doh