Hello,

consider the following code for finding a string in a file:

typedef istreambuf_iterator<char> bufit;

ifstream f("file",ios_base::binary|ios_base::in);
string s("string");
bufit it=search(bufit(f),bufit(),s.begin(),s.end());

On MSVC 6.0 / Win2k this will not work, because implementation uses
two distance() calls (one for each iterator pair) prior to any
"search" action.
distance() call on the istreambuf_iterator's pair will yield the file
lenght, adjusting read position to the end-of-file. Then, any
subsequent call to istreambuf_iterator's operator *, operator ++ will
yield end-of-file iterator, so search() will fail (not find anything).
SGI STL, for example, uses different approach, and, as i can see, the
program will work there.

The question is "Is it allright to have such an implementation-driven
behavior ?" I suspect it is, because standard says nothing on how
search() should be implemented, and, besides, MSVC's implementation
will work in all other situations.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"sahn0" <superone@mail.ru> wrote in message news:ed2d8ba5.0106210106.46947347@posting.google.com...

> typedef istreambuf_iterator<char> bufit;
>
> ifstream f("file",ios_base::binary|ios_base::in);
> string s("string");
> bufit it=search(bufit(f),bufit(),s.begin(),s.end());
>
> On MSVC 6.0 / Win2k this will not work, because implementation uses
> two distance() calls (one for each iterator pair) prior to any
> "search" action.
> distance() call on the istreambuf_iterator's pair will yield the file
> lenght, adjusting read position to the end-of-file. Then, any
> subsequent call to istreambuf_iterator's operator *, operator ++ will
> yield end-of-file iterator, so search() will fail (not find anything).
> SGI STL, for example, uses different approach, and, as i can see, the
> program will work there.

Yep. Template function search is specified to take forward iterators.
Input iterators do not meet its basic requirements. I agree that it's
stupid for distance to take input iterators and render them useless
for any other work, but that's the way the C++ Standard reads.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

sahn0 wrote:
>
> consider the following code for finding a string in a file:
>
> typedef istreambuf_iterator<char> bufit;
>
> ifstream f("file",ios_base::binary|ios_base::in);
> string s("string");
> bufit it=search(bufit(f),bufit(),s.begin(),s.end());
>
> On MSVC 6.0 / Win2k this will not work, because implementation uses
> two distance() calls (one for each iterator pair) prior to any
> "search" action.
> distance() call on the istreambuf_iterator's pair will yield the file
> lenght, adjusting read position to the end-of-file. Then, any
> subsequent call to istreambuf_iterator's operator *, operator ++ will
> yield end-of-file iterator, so search() will fail (not find anything).
> SGI STL, for example, uses different approach, and, as i can see, the
> program will work there.
>
> The question is "Is it allright to have such an implementation-driven
> behavior ?" I suspect it is, because standard says nothing on how
> search() should be implemented, and, besides, MSVC's implementation
> will work in all other situations.
>

search takes a forward iterator.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]