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.
> 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.
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
> 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
> 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
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'
> 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
Thanks for the time and help!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk