Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-10-21 08:05:54

At 12:28 PM 10/20/2003, Pavol Droba wrote:

>iterator_range is merely an utility to make some tasks of in the library
>easier. I don't know why do you pay so much attention to it. ...

Because in the current underspecified documentation iterator_range appears
to take any sequence denoted by an iterator range and turn it into a
container which can then be used in the algorithms which take ContainerT
arguments. This makes the algorithm interfaces look flexible enough that
iterator range interfaces (like the current STL) are unnecessary.

Take trim_left as an example. The template parameter is ContainerT, which
isn't further defined. From the name, it would be easy to assume the
requirements were very general, such as the "Container Requirements" table
65 in 23.1. It would be easy to jump to the conclusion that these
requirements could be met by iterator_range.

But by reading the code, we find that trim_left works by calling
ContainerT::erase. That means the actual requirement is tighter; the
container has to be mutable and must support erase. There are lots of
useful cases, including C arrays and the pseudo-container produced by
iterator_range, which don't meet that requirement.

Seen in that light, the trim_left style is more limited than the
traditional STL style which specifies ranges as a pair of iterators. The
library seems to acknowledge this by actually implementing trim_left and
other algorithms as wrappers around traditional STL style interfaces in
namespace detail.

>Don't you think, that there is a time to look beyon the STL? Look the
>for so-much wanted container_traits and now being-developed
>I personaly think, that the STL interface is obsolete and should be
>replaced with something more simplier to use. Therefor the string_algo
>library abandons the STL like interface completely in the favor of new,
>container-oriented one.

The problem is that the proposed container-oriented interface won't handle
many common sequences, such a C arrays. It won't handle operations on a
sequence which is a portion of a longer sequence. The STL interface will
handle these cases. So no, I don't think "the STL interface is obsolete."

>But I don't understand your point about the implementaion of algorithms
>being in the detail namespace. What's wrong with it, and what additional
>documentation do you request?
>Even in the STL specification, the definitions of the algorithms
>are quite vaque in the terms of the implementation.

The issue isn't implementation, it is the lack of requirements on types
specified as template parameters, and the lack of preconditions, exceptions
thrown, postconditions, and other firm specifications for functions.

Without that fundamental documentation, it doesn't seem possible to
evaluate the proposal.


Boost list run by bdawes at, gregod at, cpdaniel at, john at