From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-11-26 13:14:43
----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> (BTW, renaming the function to "find_T_and_return_iterator" is not
something
> that I am very keen of :). Still, even for algorithms, having a "type"
> interface somewhere in a "backyard" is IMO an obligatory option, because
it
> makes combination of those compile-time functions and passing them around
> much easier. For example, one can easily implement 'transform' algorithm
in
> terms of 'mpl::for_each' and 'mpl::push_back' exactly because 'push_back'
> supports "type" interface, so you can pass it to 'compose_*' (which
produces
> a function class with "type" interface too :):
>
> template<
> typename InputSequence
> , typename OutputSequence
> , typename UnaryOperation
> >
> struct transform
> {
> typedef typename mpl::for_each<
> InputSequence
> , OutputSequence
> , mpl::compose_f_x_hy<
> mpl::push_back<mpl::placeholder,mpl::placeholder>
> , UnaryOperation
> >
> >::state sequence;
> };
Except, please remember that repeated push_backs on a type_list can be
horribly inefficient (at compile-time). It would be good to have an
algorithm framework based on this:
template <class Sequence, class FwdFunction, class BackwardFunction, class
Initial> two_way_accumulate...
Think of it as mpl::accumulate which calls FwdFunction on the way in to the
recursion and BackwardFunction on the way out. Then we could implement
transform in terms of push_front.
-Dave