Re: [boost] Re: Beyond Objects [was: Re: Re: review request: container_traits]

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-06 21:18:12

On Mon, Oct 06, 2003 at 09:37:00PM -0400, David Abrahams wrote:
> Brian McNamara <lorgon_at_[hidden]> writes:
> > 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
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Your language, if not your thinking, is somewhat muddled at this
> point.  Maybe you need to rephrase for the rest of us?  Either an
> array satisfies the Container concept or it doesn't.  Unless you're
> changing the standard Container concept, it doesn't.

My understanding is:

An array is not a Container (it does not model the concept described by
the standard).

The original container_traits proposal was designed with one of its
goals being: to allow some data types (like arrays) which do not model
the concept to be viewed through a uniform interface that makes them
appear as if they do model the concept.

For each attribute in the Container concept, there is a corresponding
attribute inside container_traits.

For every type that models the Container concept, access to the
concept attributes via container_traits yields the same results as
"direct" access to the attributes.  For example:
   typedef vector<int> V;
   V v;
   container_traits::value_type<V>::type === V::value_type
   // and also for iterator_type, etc.  Maybe also for stuff like
   container_traits::begin(v) === v.begin()
   // but I haven't studied the actual container_traits proposal well
   // enough to know if it includes stuff like this.

For some types which do not model the Container concept,
container_traits provides a way to view these types as thought they did
model the concept.  For example:
   typedef int A[10];     // or whatever the syntax is here, I forget
   A a;
   container_traits::value_type<A>::type === int
   container_traits::begin(a) === &a[0]

Let me know if my understanding here is flawed at any point along the
line.

Of course, the utility of container_traits is thus that you can
 - take any generic algorithm which works on Containers
 - rewrite it to access Container attributes via container_traits
   instead of accessing these attributes directly
 - now your new algorithm
    - behaves exactly the same on types which model Container
    - also now works on some other Container-like types (e.g. array)

Effectively container_traits helps defines a new concept.  We might
call this new concept ContainerAsViewedViaContainerTraits.  It is a
super-concept (anti-refinement) of Container, in that
 - for every type T which models Container
    - T also models ContainerAsViewedViaContainerTraits

-- 
-Brian McNamara (lorgon_at_[hidden])