# Boost :

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2003-01-02 00:45:45

> > Perhaps it is a good idea to add those missing operators to
> > the MPL?
>
> It is! They are not there only because you are the pioneer, here. The
> followers will be very grateful :)

See other message.

> It's not that frightening, but I understand :). I'll try to do something
> about documenting the major workaround techniques/constructs.

Awesome.

> Personally, I would make it even more shorter by getting rid of explicit
> comparison with zero:
> typedef typename mpl::apply_if< N, ... ...

Duh, of course. If there ever is a prize for the best way to make things
Honestly, at one point I was considering writing a meta-function called
equal_to_zero, because I needed it a lot.
I guess

N

is a lot shorter than

mpl::equals_to< N, mpl< N::value_type, 0 > >

> Some of these issues are probably caused by absence of some common
> primitives in the library. If you cite your typical use cases when you
have
> to resort to recursion (and when that bothers you :), together we might be
> able to classify them and find out if there is anything on the library
side
> we can do to support them better - or may be find the ways to do that with

Well, the biggest headache is caused by an O(n * m) algorithm that does
something like the following:

list_n and list_m are typelists (or vectors) of integral_c< size_t >'s.
list_result is an empty typelist at the start

for_each_in( list_n )
for_each_in( list_n )
if ( ! contains( list_result, list_n[ i ] ^ list_m[ i ] )
insert( list_result, list_n[ i ] ^ list_m[ i ] );

So list_result acts as a set (I'm still considering to write an mpl::set),
and it contains the xor of all combinations of elements from list_n and
list_m.
I have the meta-function written and it's compiling, but I can only
instantiate it for very small lists (1 or 2 elements).

> For instance, here's how a higher-level version of the 'bit_count'
algorithm
> might look like:
>
> template< typename N >
> struct bit_count
> {
> typedef typename for_<
> pair< int_c<0>, N >
> , _2
> , pair<
> next< _1 >
> , bit_and< _2, prior< _2 > >
> >
> >::type type;
> };
>
> Would something like this make your life easier?

Yes! Most definitely. I would have some difficulties transitioning to this
way of thinking (even now I still have a few places where I should use an
iter_fold, but resort to old-scool meta-programming techniques instead), but
I would totally try using it. Not only is it easier to code (imho), but the

> > Also, I'll need to start thinking about

>
> The current sources implement the unrolling a little bit different; I will
> be documenting it sometime in the future, meanwhile just ask when you get
to
> it.

Thanks for the time and help!

Regards,

Jaap Suter