Re: [boost] Re: loki::type_list == boost::mpl::list_node

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-15 08:46:03

----- Original Message -----
From: "Hamish Mackenzie" <hamish_at_[hidden]>

> > While the simple-looking implementation may
> > use less compile-resources for short lists, it will always use more
> > template nesting for long lists and preliminary tests show that it
also
> > compiles more slowly.
>
> I don't know which the "simple-looking implementation" is?

I meant the low-level, partial-specialization, typelist-specific one.

> I thought
> the general consensus was that simplicity was largely in the eye of
the
> beholder.

OK, you're right. I hope I've clarified above.

> As I understand it, both result in nesting, ether of N * count_if or N
*
> (for_loop + for_loop_iteration). (I don't seem to have source for
> mpl::fold so I am basing this on the next_if implementation).

No, read the paper. The library uses loop unrolling to decrease nesting
depth.

> > In order to optimize for short lists you'd need to
> > make specializations for, say, all lengths up to 10. If performing
> > matches on those partial specialization doesn't tax the compiler, it
> > might be a win. However, that's a big if.
>
> If it did work though, you could do it for the recursive part as well,
> which might improve performance for long lists. But I am speculating
> again.

If I had to speculate, I'd say that would use lots of compile-time
resources. Just think of the cycles required to determine that:

    template <class T1, class T2, class T3, class T4, class T5, class
T6, class T7>
    struct
count_if<cons<T1,cons<T2,cons<T3,cons<T4,cons<T5,cons<T6,cons<T7,
cons<nil,nil> > > > > > > > > > >

is a more-specialized match for some list than

    template <class T1, class T2, class T3, class T4, class T5, class
T6>
    struct
count_if<cons<T1,cons<T2,cons<T3,cons<T4,cons<T5,cons<T6,cons<nil,nil> >
> > > > > > >

But, let's not speculate. If you really believe this direction is
fruitful, you know where to find the source. Try some experiments and
make some measurements. Speaking personally, it seems like a bad
investment to me.

> What are your thoughts on the other issues involved with including two
> implementations?
>
> Pros
> * Improved self documentation

I don't think duplicating functionality improves self documentation.

> * Testability (ie. you can check one implementation against the other)

Not worth it, IMO. Especially since getting both implementations to run
in the same program breaks the ODR (or requires renaming hacks).

> * Possible compile time performance improvement

I don't believe in that, not one bit. You'd have to prove it.

> * Possibly shorter error messages

You'd have to prove that, too. Decreased nesting due to loop unrolling
will also shorten error messages.

-Dave