Re: [boost] Re: string_algo Formal Review

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-22 10:26:08

On Wed, Oct 22, 2003 at 09:34:44AM -0400, David Abrahams wrote:
> Pavol Droba <droba_at_[hidden]> writes:
> 
> > On Tue, Oct 21, 2003 at 05:48:27PM -0400, David Abrahams wrote:

[snip]
 
> >
> > Sorry, the definition is not exact. I have used the C++ syntax, but
> > I merely wanted to list the requiremnts. The fact is, that it is not
> > required, that f.e. a container have .begin() member function. It is
> > only required, that such a function is accessible. Having the
> > container_traits and freestanding begin(), it is well defined for
> > C-arrays.
> 
> You still need a tight definition of the requirements.
>

Definition will be provided in docs. The format will be the same as the
concept definitions which are already there. 

As far as I see, this concept should be defined in the terms of operations 
that are provided by container_traits.

<example>

        Valid expressions | Return Types                                      | Effects
                                                         |                                                   |
        begin(C) 			| container_const_iterator<C>::type when C is const | returns an iterator pointing
                                                        | container_iterator<C>:type  when C is mutable     | to the first element in the container

        end(C) 				| container_const_iterator<C>::type when C is const | returns an iterator pointing
                                                        | container_iterator<C>::type when C is mutable     | after the last element in the container

        size(C)				| container_size_type<C>::type                      | returns the number of elements in the container

</example>

container_traits can be then described as a facility which provides this interface for
build-in types like C-arrays and STL containers

[snip]
> 
> > What I meant with the non-result argument is of cause, "a container
> > argument with non-result type".  
> 
> Since I don't know what a container is (there seems to be some
> fuzziness around the area of built-in arrays) this only helps a
> little.
> 

Std 23.1.1:
"Containers are objects that store other objects. They control allocation and deallocation of these objects
through constructors, destructors, insert and erase operations."

Simplification of a container used as a base for InputContainer is something like this:
"Containers are objects that store other objects. They have an interface to access the stored objects"

Minimal container requirements are specified by InputIterator concept.

[snip]
 
> I'm sorry, we seem to have a disagreement about the importance of
> tight specification.  Others may disagree with me, but personally I
> think you should take this more seriously.

I'm confident now, that the precise specification is needed. I see, that
the level of precision, which I have offered was lower then expected.
I'll try to be more exact. Problem is that some facts are obvoius to me,
and I have not justified well, which are also obious to a user or a reviewer.

Regards,

Pavol