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:
> ... // 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:
> ... // 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.
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
> Mostly unrelated to the above:
>> How do you express
>> 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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk