"Dirk Schreib" <Dirk.Schreib@uumail.de> writes:

> I'm getting confused with the unexpected behaviuor of ranges inside
> the C++ Standard Library. Usually ranges are denoted by a begin and an
> end iterator.
>
> But sometimes e.g. in basic_string ranges are described with the beginning
> position and the length. If you frequently mix STL algorithms with
> basic_string
> methods, some unexpected results will drive you (or your debugger) crazy
> :-).
>
> Additionaly the find methods in basic_string return a position and NPOS if
> the search fails. What are the advantages over returning an iterator with
> basic_string::end() as a "not found"-indicator?

The reasons are historical: basic_string was originally designed
before the STL was incorporated into the C++ standard.  One reason the
basic_string interface is so huge (a hundred member functions and
another couple dozen nonmember functions, unless I've lost count) is
that it's the sum of two or three different designs.  Nothing was
taken away, only added.

I don't think the results are pretty; nobody does.  It was mostly a
pragmatic decision that code using old interfaces shouldn't be broken
unless it was absolutely necessary.

I don't think there's any particular advantage of using
container+index+length (rather than an iterator pair) to designate a
range, or of returning npos (rather than a past-the-end iterator) to
designate failure.  It's just another style of interface.  If you
don't like that style, you don't have to use it; everything works just
as well using ordinary STL algorithms.

---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Matt Austern" <austern@sgi.com> wrote in message
news:fxtem6tqgrm.fsf@isolde.engr.sgi.com...
[...]
> I don't think there's any particular advantage of using
> container+index+length (rather than an iterator pair) to designate a
> range, or of returning npos (rather than a past-the-end iterator) to
> designate failure.  It's just another style of interface.  If you
> don't like that style, you don't have to use it; everything works just
> as well using ordinary STL algorithms.
But there are advantages. Indices can't be invalidated in the way that
string iterators can. The same thing applies to vector iterators vs vector
indices.

I'm not sure that separate implementations of the same algorithms are
necessary, though, but they can be convenient.

Sam Lindley



---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I'm getting confused with the unexpected behaviuor of ranges inside
the C++ Standard Library. Usually ranges are denoted by a begin and an
end iterator.

But sometimes e.g. in basic_string ranges are described with the beginning
position and the length. If you frequently mix STL algorithms with
basic_string
methods, some unexpected results will drive you (or your debugger) crazy
:-).

Additionaly the find methods in basic_string return a position and NPOS if
the search fails. What are the advantages over returning an iterator with
basic_string::end() as a "not found"-indicator?

Ciao
  Dirk


---
[ 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://reality.sgi.com/austern_mti/std-c++/faq.html              ]