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
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
> 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
// \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 > >
typedef typename mpl::apply_if<
mpl::integral_c< typename N::value_type, 0 >
mpl::integral_c< size_t, N::value & (N::prior::value) >,
Definitely a lot shorter.
I need to change my algorithms in some other places too I think. However,
style of programming and the associated amount of recursion does not leave
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
Also, I'll need to start thinking about
> 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
> 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
> at work).
> Probably the opposite - the more of the stuff you are doing is done
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk