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