Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-06 14:02:20

On Mon, Oct 06, 2003 at 02:53:58PM -0400, David Abrahams wrote:
> Brian McNamara <lorgon_at_[hidden]> writes:
> > On Mon, Oct 06, 2003 at 07:36:22AM -0400, David Abrahams wrote:
> > 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.

I now (finally!) see what you are talking about.

I will have to think about this deeply before I can consider how it
affects my whole stance on the topic.

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

Thanks for this one last message.

Sorry that we spent so much time spinning our wheels yesterday.

-Brian McNamara (lorgon_at_[hidden])

Boost list run by bdawes at, gregod at, cpdaniel at, john at