Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2003-10-05 16:03:00

Brian McNamara <lorgon_at_[hidden]> writes:

> On Sat, Oct 04, 2003 at 05:48:19PM -0400, David Abrahams wrote:
>> Brian McNamara <lorgon_at_[hidden]> writes:

> One solution, which I think is the solution you are suggesting, is to
> make individual traits:
> container_value_type<C>::type
> container_iterator_type<C>::type
> ... // etc for each "foo"
> This solves both of the problems above: each type is computed
> "independently", and each trait is an MPL metafunction. However the
> weakness here is that now we have polluted the namespace with many
> new names (rather than just one ("container_traits")),

So use a nested namespace (?)

What I see above is a very complicated solution to a very simple
problem. I don't think there's any need to do something creative
when we can do something that's already proven to work.

> and the conceptual-relatedness of the group of traits is no longer
> expressed by a structural grouping in the code.

Which is good because it allows non-intrusive extension. And there
*will* be extensions. We really shouldn't want the definition of
container_traits to get progressively more bloated as they are added.

> In order to have our cake and eat it too, I propose this:
> container_traits<C>::value_type<>::type
> container_traits<C>::iterator_type<>::type
> ... // etc for each foo
> Now we reap the advantages of both solutions. That is
> - we have conceptually grouped related traits into a single traits
> class (container_traits<C>)
> - each individual trait is an MPL metafunction (e.g.
> container_traits<C>::value_type<>)

That's a nullary metafunction, which isn't very useful if you want to
use it in an MPL lambda expression. Since C is already bound into it,
you can't apply it to different containers.

> - asking for one trait (e.g. value_type) does not cause other trait
> values (e.g. iterator_type) to get computed
> - we have only introduced one name (container_traits) into the (boost)
> global namespace
> Agree/disagree?
> Mostly unrelated to the above:
>> How do you express
>> argument_type<F,_1>::type
>> with that system??
> No clues here; sadly I still only a tiny bit about MPL, just enough
> (hopefully!) to participate in this discussion.

Well, the answer is that you can't, unless you wrap it into a proper
metafunction... and if you're going to do that, why not just start
with a proper metafunction to begin with? It's the same problem as

Dave Abrahams
Boost Consulting

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