Re: [boost] string_algo Formal Review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-22 01:23:05

On Tue, Oct 21, 2003 at 09:08:05PM -0400, Beman Dawes wrote:
> At 04:22 PM 10/21/2003, Pavol Droba wrote:
> 

[snip]
> >
> >These properties are exactly the properties the STD Container concept,
> >except of construction/destuction method, and swap.
> 
> OK, good. This is starting to fill in the missing pieces. Presumably you 
> will change the name of template parameters to InputContainerConcept where 
> applicable?

I will and it will be accompanied by a specification in docs. Question is,
if I should do it during the review, or it would be enough to do it afterwards?

> Other comments:
> 
> Specifying the types and operations as member signatures is precise, but is 
> really overspecification. The Standard Library approach of specifying a 
> requirements table is precise, yet leaves the implementor a bit of wiggle 
> room to meet the specification. I don't think it matters at this stage, but 
> others may have stronger opinions.

I have used C++ syntax, but I haven't mind it as a piece of code. Try to
look at it as table of required feature.

> The Standard Library clause 23.1 has five or so requirements tables 
> (Container, Reversible Container, Sequence, etc). Where the docs talk about 
> "the Std Container concept", it would be clearer if they said "the Standard 
> Library Container requirements table 65 in section 23.1" or something 
> similar. That's a bit pedantic, but more precise.
> 

Seems reasonable, I will change the wording.

> >This concept allows to access the values contained in the container,
> >without altering the state of the container itself. It means, [that] it
> >is not possible to change, what elements are contained by this container.
> >It is sufficient for those arguments in algorithms with are not altered
> >(i.e. immutable arguments)
> 
> Presumably you will then have a similar concepts for algorithms needed 
> erase or other members? That will resolve the current confusion caused by 
> using the same name (ContainerT) for template parameters with different 
> requirements.

Well, the Sequence is sufficient model for all algorithms in string_algo library,
where mutable operations are need. 
Currently I don't see a major benefit in a refinement of this concept.

> >container_traits, one of the core facilities defined in theis library,
> >wraps this concept,
> >and allows to access some of legacy C structure (C-arrays and string) 
> >using
> >this interface.
> >
> >iterator_range also implements this concept for a pair of iterators.
> 
> OK, as soon as it is known exactly what algorithms require this concept 
> (rather than EraseableContainer (or whatever), then it becomes possible to 
> understand which algorithms would work with C style arrays or other 
> almost-containers, and as many other gradations of functionality as there 
> are requirement concepts.

So let me sumarize the requirements for the container arguments:

1. for non-result type container arguments (see my previous posts) InputContainerConcept is required.
2. For all others SequenceConcept is required. 

There are some exceptions to point 2, but given the fact, that the requirements are lower, it is safe
to assume the SequenceConcept as requirement.

Regards,

Pavol