[boost] Re: review request: container_traits

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-06 13:53:58

Brian McNamara <lorgon_at_[hidden]> writes:

> On Mon, Oct 06, 2003 at 07:36:22AM -0400, David Abrahams wrote:
>> Second, even if we use Brian's scheme, nesting all of these things
>> still has an efficiency impact, even though they're templates.
>> Furthermore it requires the syntactically heavy template keyword in
>> dependent contexts.
>
> These are both true (I should have owned up to these limitations in my
> previous message).
>
>> The insistence that everything needs to be grouped together is the
>> same as insisting that all concept requirements on regular classes
>> must be expressed as member functions and not as free functions.  
>
> I disagree with this.  The concepts (and traits) themselves are still
> "extrinsic".  The only thing the "grouping" does is say "hey, since the
> Container concept is already known and fixed, we provide a convenient
> way to access container traits uniformly here in this namespace (or
> class template, or however it gets implemented).  One "group" which
> contains all of the individual traits as members is conceptually easier
> to grok than two dozen individual traits entities.

I'm sure there will be traits that are of interest even if they don't
have a direct relationship to the container requirements.  That's the
point: container_traits is-not-a container.  It gives arbitrary
information *about* a container, the scope of which is currently
bounded by the grouped design.  

For an analogy, let's look at iterators.  Without changing the current
iterator concepts, we might want to know if an iterator can be
incremented without throwing an exception, or whether it returns an
lvalue when dereferenced, neither of which is completely reflected in
iterator_traits.  I assert that grouped iterator_traits is a mistake,
in part because you can't ask those questions without either changing
iterator_traits or producing an unbalanced design with one group and
lots of little independent traits metafunctions.

> Grouping does _not_ hinder the overall design flexibility (e.g., I can
> still make a FooContainer work with container_traits in a completely
> post-hoc fashion (using template specialization, rather than changing
> the existing FooContainer)).

I was talking about the fact that container_traits needs to be
modified, not that FooContainer has to be modified.  I can't even
imagine what you're referring to.

> I see Mat has started a new thread topic ("Beyond Objects"), and it's
> probably wise to take the continuation of this discussion there.

But anyway, I promised to butt out after my last posting, so I'm
*really* butting out now.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com