This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: C++ file processing
- From: LLeweLLyn Reese <llewelly at lifesupport dot shutdown dot com>
- To: Justin Findlay <farquharsoncraig at yahoo dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: 03 Jul 2003 08:08:42 -0700
- Subject: Re: C++ file processing
- References: <20030702231231.88269.qmail@web13205.mail.yahoo.com>
- Reply-to: gcc-help at gcc dot gnu dot org
Justin Findlay <farquharsoncraig@yahoo.com> writes:
> Why doesn't ifstream overload operator>> for const
> char * types so that one could do this:
>
> string keep_this_string;
> ifstream fin( "fin.txt" );
> while ( fin )
> {
> fin >> "Ignore this string everywhere it occurs" >>
> keep_this_string >> "Ignore something else";
I am not at sure I understand. The primary stream use of the left hand
argument of operator>> is a place to write the extracted data
to. The secondary use is a manipulator which changes the
formatting state of the stream. You seem to be suggesting a kind
of operator>> which instead uses the right hand side as an
indicator of what to ignore. This is not consistent with either
the primary or secondary existing operator>> idioms. My second
objection is that your notion seems fragile; IMO it is rare for a
file format to both require that a piece of text exactly match a
specific string, and then ignore it.
Probably no-one thought of it. In any case, it needs to be better
explained, and perhaps even then it would be deemed too
confusing. I had to read your several times to understand what
you meant - assuming I understand it now.
> use_it( keep_this_string.c_str() );
> }
>
> How about an istream member getline() that returns a
> formatted string:
>
> istringstream iline;
> iline.str( fin.getline() );
> iline >> "Ignore this string everywhere it occurs" >>
> keep_this_string >> "Ignore something else";
> use_it( keep_this_string.c_str() );
>
> or even just:
>
> string ilinestr;
> fin.getline( ilinestr );
[snip]
This suggestion I do not understand at all.