Adding a istream_iterator ctor with a delimiter.
Ed Smith-Rowland
I was writing a little program to parse a tab delimited file.
Each line has several strings (which can contain spaces) and numbers.
The spaces in the strings spoil usage of istream_iterator in this
problem. This is obviously surmountable but the more I think about it
the more surprising this is.
It looks to me like there is an old oversight in istream_iterator.
It
would be nice to be able to add a delim string ctor:
istream_iterator (istream_type & __in, char_type * __delim);
That way, ostream_iterator(ostream_type & __out, char_type * __delim)
and the above would do the opposite things and be a useful, intuitive
pair of utilities.
Is there any reason this was not done? Could it be added as a DR?
Ed
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
hak...@gmail.com
> istream_iterator (istream_type & __in, char_type * __delim);
I think the istream_iterator was not designed for what you wish it
was. As a simple iterator for the istream, it does a great job. I
think a better proposal would be for a new iterator.
> That way, ostream_iterator(ostream_type & __out, char_type * __delim)
> and the above would do the opposite things and be a useful, intuitive
> pair of utilities.
The ostream_iterator already has a constructor accepting an
ostream_type& and char_type*. Thus, this could not be added.
The reason I'm responding (since I think all I've said thus far will
be said again more than once) is to recommend making a
delimited_iterator wrapper, or something like that. For example:
std::copy( delimited_iterator( std::istream_iterator(cin), ' ' ),
delimited_iterator<std::istream_iterator,char>(), cin );
or
std::copy( delimited_iterator( std::istream_iterator(cin), ' ' ),
delimited_iterator( std::istream_iterator(), '' ), cin );
This would actually require that delimited_iterator be a function that
returns an iterator (like DelimitedIterator). Otherwise, each call
above would have to explicitly use <>'s to show the types.
It's midnight and I don't feel like testing the idea out at the
moment, but I at least wanted to share it. Perhaps tomorrow, I will
give it a shot.
Also: This is one problem that the concept of ranges fixes. I don't
much like ranges and they aren't in the standard (yet?), but you might
look into it.
Ed Smith-Rowland
>
> I was writing a little program to parse a tab delimited file.
> Each line has several strings (which can contain spaces) and numbers.
>
> The spaces in the strings spoil usage of istream_iterator in this
> problem. This is obviously surmountable but the more I think about it
> the more surprising this is.
>
> It looks to me like there is an old oversight in istream_iterator.
> It
> would be nice to be able to add a delim string ctor:
>
> istream_iterator (istream_type & __in, char_type * __delim);
>
> That way, ostream_iterator(ostream_type & __out, char_type * __delim)
> and the above would do the opposite things and be a useful, intuitive
> pair of utilities.
>
> Is there any reason this was not done? Could it be added as a DR?
>
> Ed
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
On third thought, this makes no sense.
There's really no generic, sane way to have an istream_iterator that
doesn't let the extraction operator for the type have a go at the
stream. It isn't like a normal person would want to use the number 0
to split integers.
If I really wanted to extract wulti-word phrases out of a delimited
file (which is the only thing I was concerned about - the numbers work
fine of course) a better way might be to have a little phrase class
with an extraction operator that stops on tabs (or any user specified
separator).
Scott Meyers
> If I really wanted to extract wulti-word phrases out of a delimited
> file (which is the only thing I was concerned about - the numbers work
> fine of course) a better way might be to have a little phrase class
> with an extraction operator that stops on tabs (or any user specified
> separator).
Why not just use a std::regex_iterator (or std::tr1::regex_iterator)?
Scott