[boost] Re: Using MPL on MSVC7

From: Jaap Suter (J.Suter_at_[hidden])
Date: 2002-12-30 22:41:26

> Be sure to check John Maddock's "Coding Guidelines for
> Integral Constant Expressions"
> (http://www.boost.org/more/int_const_guidelines.htm), as well

Thanks for that. I've seen it a long time ago (hence I was using
BOOST_STATIC_CONSTANT already), but some of the tips there I forgot.
For example, MSVC doesn't like operators in constant expressions as template
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? 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.
Let me know if you think this is worthwhile, and I'll come up with something
you can take a look at.

> as MPL's
> techniques to work around some of these problems.

These are not documented explicitly anywhere are they? 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.

> After you know what you are dealing with, the fix is simple:

Thanks for that! However, after your next remark, I no longer needed it in
that specific case. I do need it in a few other cases though.

> On aside note, a more efficient way to compute the number of set bits
would
> be a compile-time equivalent of this:

Thanks! All of the code from my original message is now turned into:

// \brief Meta function, returns the number of bits equal to 1 in a given
number.
// \param N Some number. Concept: boost::mpl::integral_c
// \retval ::type boost::mpl::integral_c< size_t,
                                             Number of bits equal to 1 in N
>
// \warning Don't touch default value;
// \todo Only works for unsigned types, needs to be fixed;

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.

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.

I'm doing an N^2 algorithm in a few places which is kinda heavy, so
I definitely need to fix that. I'll start looking for some function
programming tutorials that mention conversion from imperative to functional
style, I'm sure there are a few common idioms to speed things up (or reduce
recursion).

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.

> It depends on how much code you have in your library and, correspondingly,
> how much resources you are willing to spend on it, but in general I
wouldn't
> say it's doomed. For one, you can count on MPL. It does work, reliably, on
> both MSVC 7.0 and MSVC 6.5 (we use it routinely on the latter platform
here
> at work).
> Probably the opposite - the more of the stuff you are doing is done
through
> the MPL, the less portability problems you'll have.

Yeah, I just noticed. After biting through the first initial steps, it isn't
so hard after all. However, I'm still in the parsing stage and not
instantiating anything. I'm about 90% done I guess. I suppose the real
problems and limits will show up once I start instantiating these templates.

Already, I'm running into compiler error:

    e:\library\boost_1_29_0\boost\mpl\if.hpp(95) : fatal error C1076:
    compiler limit : internal heap limit reached; use /Zm to specify a
    higher limit

now. I suppose I really need to tweak my algorithms.

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. And I'm sure that you and Dave have more gold nuggets from
your experience using the MPL in real-world code.

Thanks a lot for your help.

Jaap Suter