[boost] Re: Re: Using MPL on MSVC7

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
overly complicated, please nominate me.
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
> the already existing facilities.

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
readability greatly improves as well.

> > Also, I'll need to start thinking about
> > http://www.mywikinet.com/mpl/paper/mpl_paper.html#sequences.unrolling
> > and  http://users.rcn.com/abrahams/instantiation_speed/index.html.
>
> 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