> > 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
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
