Re: [boost] Re: Re: Beyond Objects (back to containers)

From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-10 07:57:58

On Fri, Oct 10, 2003 at 11:56:45AM +0000, AlisdairM wrote:
> Pavol Droba <droba_at_[hidden]> wrote in
> news:20031010111823.GO2433_at_[hidden]: 
> 
> 
> > You are not quite right.
> > 
> > Container concept (Std.23.1) does not define an interface to manage
> > the collection elements. It merely defines a ways how to access these
> > elements. 
> 
> > There are other refinements of the Container Concept, like Sequence
> > (Std.23.2) and Associative Container (Std.23.3), that also define ways
> > how to add/remove elements. 
> 
> > So given the Container Concept, array has almost all the properties
> > needed (except for consruction and destruction) to treat it as a
> > container. 
> 
> "almost all" means we "almost model" the concept <g>
> 
> Double checking, you are right that it is constructors that give the 
> problem.  Specifically (for my example) the post-condition on default 
> constructor that size() == 0, something that can *never* be true for a 
> valid array (or wrapper)
> 
> Either way, if array is a model of the concept embodied in 
> container_traits, then this is a different concept than in the standard.
> 
> Without CVS access I cannot get a proper look at the topic of this thread 
> to see if this is a more widely useful concept though (as I suspect <G>)
> 
> I'm also not clear what it means for something to 'almost' model a concept.  
> I don't handle fuzzy logic well!  Is this a normal use of concepts/models?  
> Naively I would expect to see another (simpler) concept introduced that 
> standard-container refines, but this could be my muddling 
> concept/refinement with class/inheritence.
> 

Well, I dare to say, that "almost" in this context is quite enough. 

You don't need to know how to construct or destroy a container when you 
only need to access its content. Container traits are designed with exactly
this purpose, to give a unified interface for accessing a container content.

Constuction/desctruction is  quite a separate topic. 

Unfortunately, it is  true that in this case these two topic are mixed into 
one concept. It is not the only one case of this problem found in the standard.
(For instance iterator categories have the same problem)

Boost.Concept library has already tried to define the refinements for Container concept.
(Container and Mutable_Container). I agree with you, that there is a need to 
formalize weaker variant of Container concept which could be used as specification
for container traits.

Pavol