Consider the following code:
#include <iostream.h>
#include <fstream.h>
#include <strstream.h>
int main(void) {
ifstream is;
char buf[255];
char var_name[20];
char var_type[20];
char trash_bin[1000];
is.open(“test”);
while ( is.good() ) {
is.getline( var_name, 20, ‘,’ ); // get name
is.getline( var_type, 20, ‘,’ ); // get type
is.get( trash_bin, sizeof(trash_bin), ‘\n’ );
cout << var_name << " " << var_type << endl;
}
is.close();
return 0;
}
Program is parsing the following input file test:
a,a,10
b,B,11
c,C,
d,D,13
When compile with dinkum, parsing the third line of the file the stream
state becomes bad when doing the is.get, seems to be because the first
character is.get is looking at is a \n. Works fine with gcc. If I insert a
space after the “c,C,” it works fine.
The included dinkum C++ is pretty poor at explain what the fonction
should/shouldn’t do.
Mario,
You really need to get yourself a copy of the C++ Standard 
Under Section 27.6.1.3 Unformatted input functions:
“…get()… If the function stores no characters, it calls
seststate(failbit)…”
As per the example in the Standard (yes the Standard does actually include
useful examples), your code needs to check is.fail() and perhaps call
is.clear(is.rdstate() & ~ios::failbit) accordingly.
IMHO it’s fair enough for the Dinkum docs to assume that you have a copy of
the Standard.
But the real issue/problem is the reverse - the lack of compliance of the
GCC libs. It is the behaviour of the GCC libs that is not actually
documented anywhere.
Rob Rutherford
“Mario Charest” postmaster@127.0.0.1 wrote in message
news:b9g63q$pro$1@inn.qnx.com…
Consider the following code:
#include <iostream.h
#include <fstream.h
#include <strstream.h
int main(void) {
ifstream is;
char buf[255];
char var_name[20];
char var_type[20];
char trash_bin[1000];
is.open(“test”);
while ( is.good() ) {
is.getline( var_name, 20, ‘,’ ); // get name
is.getline( var_type, 20, ‘,’ ); // get type
is.get( trash_bin, sizeof(trash_bin), ‘\n’ );
cout << var_name << " " << var_type << endl;
}
is.close();
return 0;
}
Program is parsing the following input file test:
a,a,10
b,B,11
c,C,
d,D,13
When compile with dinkum, parsing the third line of the file the stream
state becomes bad when doing the is.get, seems to be because the first
character is.get is looking at is a \n. Works fine with gcc. If I insert
a
space after the “c,C,” it works fine.
The included dinkum C++ is pretty poor at explain what the fonction
should/shouldn’t do.
“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:b9mlm9$4a3$1@inn.qnx.com…
Mario,
You really need to get yourself a copy of the C++ Standard >
Yep seems like I do 
Under Section 27.6.1.3 Unformatted input functions:
“…get()… If the function stores no characters, it calls
seststate(failbit)…”
As per the example in the Standard (yes the Standard does actually include
useful examples), your code needs to check is.fail() and perhaps call
is.clear(is.rdstate() & ~ios::failbit) accordingly.
IMHO it’s fair enough for the Dinkum docs to assume that you have a copy
of
the Standard.
I Agree
But the real issue/problem is the reverse - the lack of compliance of the
GCC libs. It is the behaviour of the GCC libs that is not actually
documented anywhere.
Wonder if gcc 3.0 has more compliant C++ lib …
Rob Rutherford
Thanks Robert!
“Mario Charest” postmaster@127.0.0.1 wrote in message
news:b9g63q$pro$> 1@inn.qnx.com> …
Consider the following code:
#include <iostream.h
#include <fstream.h
#include <strstream.h
int main(void) {
ifstream is;
char buf[255];
char var_name[20];
char var_type[20];
char trash_bin[1000];
is.open(“test”);
while ( is.good() ) {
is.getline( var_name, 20, ‘,’ ); // get name
is.getline( var_type, 20, ‘,’ ); // get type
is.get( trash_bin, sizeof(trash_bin), ‘\n’ );
cout << var_name << " " << var_type << endl;
}
is.close();
return 0;
}
Program is parsing the following input file test:
a,a,10
b,B,11
c,C,
d,D,13
When compile with dinkum, parsing the third line of the file the stream
state becomes bad when doing the is.get, seems to be because the first
character is.get is looking at is a \n. Works fine with gcc. If I
insert
a
space after the “c,C,” it works fine.
The included dinkum C++ is pretty poor at explain what the fonction
should/shouldn’t do.