Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-28 10:38:36

On Wednesday, November 28, 2001, at 10:10 AM, Mark Rodgers wrote:

> From: "David Abrahams" <david.abrahams_at_[hidden]>
>> Actually, the type list implementation in MPL
>> isn't the (most) interesting part. The algorithms
>> are more interesting, IMO.
> Well because template metaclasses can't have member
> metafunctions,

Can't they?

template <class H, class T>
struct node
        template <class Ignored = nil_t> // nullary metafunction
        struct size
                static int value = T::template size<>::value + 1;

> the distinction between list implementation
> and algorithm is somewhat blurred. I see size and at,
> for example, as being part of the list implementation
> whereas distance and find are algorithms. All four
> are interesting :-)


> The key point for me is does it matter to users whether
> they write loki::length<x>::value or mpl::size<x>::value
> and do they care how whatever they write is implemented?
> I'd like us to agree that everyone should write
> mpl::size<x>::value, even if an initial release
> implemented this in a simple recursive manner. When and
> if the full mpl is accepted into boost, the implementation
> could change completely, but no-one would need to care.

Except for the costs of template instantiation.

> If Andrei were to rework his type list submission so that
> it matched the mpl interface, we could get it accepted
> earlier than mpl and people could begin to use it. We
> could then go on to debate the merits of the rest of
> the mpl and the alternative implementation without worrying
> that we'd already accepted a completely different and
> incompatible type list.

It's not a bad idea, but mpl has some specific idioms which need some
examination. For example, in mpl, a metafunction is spelled this way:

struct function
        template <class T, ...>
        struct apply
                typedef ... type;
                static ... const value = ...;

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