From: Pavol Droba (droba_at_[hidden])
Date: 2003-10-10 06:18:23
On Fri, Oct 10, 2003 at 10:25:30AM +0000, AlisdairM wrote:
> Brian McNamara <lorgon_at_[hidden]> wrote in news:20031007010744.GA21887
> @lennon.cc.gatech.edu:
>
>
> > Maybe another way to state my point is that I see container_traits as a
> > "concept wrapper" rather than a "module". It takes a concept (as
> > described by, e.g., the standard) and wraps it in a more convenient and
> > generic interface. This allows more types to model the concept (e.g.
> > an array can be a Container when viewed via container_traits) and
> > provides a single named entity which clients of the concept (e.g.
> > generic functions) can use to get at the concept attributes.
>
> Minor nitpick, but an array can never be a Container conforming to the
> standard, as there are requirements to add/remove elements and arrays are
> fixed.
>
> I have tried to address this in a proposal to standardise boost::array, but
> I'm not sure we'll see changes to the Container concept adopted <g>
>
> So if arrays can be modelled by container_traits, it is modelling a
> different concept than that in the standard (although arguably a more
> useful one!)
>
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.
Pavol