Re: [boost] string_algo Formal Review

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 
list
 >for so-much wanted container_traits and now being-developed
 >container_algo(s).
 >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.

--Beman