RE: [boost] Re: Using MPL on MSVC7

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2002-12-31 07:58:44

Jaap Suter wrote:
> parameters. I did this in a few places for operators that MPL doesn't
> implement (left shift, bitwise or, etc.).
> Now I'm putting them in a seperate static constant first, and 
> then using that constant as a template parameter. That really 
> solves a _lot_ of my MSVC problems.
> 
> 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 :)

> I would be willing to do it, considering it is probably just going to 
> be a copy paste and changing an operator here and there in a lot of 
> boiler-plate code.

Wonderful, I only was going to suggest it! I'll be happy to work with you on
it.

> > as MPL's
> > techniques to work around some of these problems.
> 
> These are not documented explicitly anywhere are they? 

Nope, not yet.

> I can't seem to find more info on http://www.mywikinet.com/mpl/,
> and I'm not man enough to dive in the MPL source-code :) hehe.

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

> template < typename N, typename Result = mpl::integral_c< 
> size_t, 0 > >
> struct num_bits_set
> {
>     typedef typename mpl::apply_if<
>             typename mpl::equal_to<
>                 N,
>                 mpl::integral_c< typename N::value_type, 0 >
>             >::type,
> 
>             Result,
>             num_bits_set<
>                 mpl::integral_c< size_t, N::value & 
> (N::prior::value) >,
>                 typename Result::next
>             >
>     >::type type;
> };
> 
> Definitely a lot shorter.

Personally, I would make it even more shorter by getting rid of explicit
comparison with zero:

    template< 
          typename N
        , typename Result = mpl::int_c<0>
        >
    struct num_bits_set
    {
        typedef typename mpl::apply_if<
              N
            , num_bits_set<
                  mpl::int_c< N::value & (N::prior::value) >
                , typename Result::next
                >
            , Result
            >::type type;
    };

> 
> I need to change my algorithms in some other places too I 
> think. However, the functional style of programming and the 
> associated amount of recursion does not leave much flexibility.

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.

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? 

> 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.

> By the way, would it be worthwhile to create an 'Effective 
> MPL'  wiki page with some common gotchas on the different 
> compilers? We could refer to the document on Integral Constant 
> Expressions, we could mention the 'early template instantiation' 
> and the work-around, and we could mention the lambda complications.

Very worthwhile for sure.

Aleksey