Jaap Suter wrote: > > Nifty! You're using one of my favorite metaprogramming tricks, the > > default template parameter which allows you to avoid creating a > > separate implementation template. I almost forgot about that one, > > it's been so long since I've been able to use it. > > Funny you mention that. I've been meaning to ask for its > appropriateness on this list. After all, we are exposing > implementation details in the interface which is not something > I would recommend on a daily basis.
At least one has to be careful :). There are at least two situations when default template parameters affect the observable library behavior: 1) adding default _non-type_ template parameters "disqualifies" a metafunction from participating in lambda expressions: template< typename N , int one_before_previous_ = 0 , int previous_ = 1 > struct fibonacci { // ... }; typedef fold< range_c<int,0,10> , int_c<0> , plus< _1, fibonacci<_2> > >::type sum; // compilation error here! BOOST_STATIC_ASSERT(sum::value == 88); 2) adding a default template parameter to a metafunction which number of parameters is already equal to BOOST_MPL_METAFUNCTION_MAX_ARITY results in the same negative effect: // BOOST_MPL_METAFUNCTION_MAX_ARITY == 5 template< typename N1 , typename N2 , typename N3 = integral_c<int,0> , typename N4 = integral_c<int,0> , typename N5 = integral_c<int,0> , typename result_ = integral_c<int,0> > struct my_fun { // ... }; typedef fold< range_c<int,0,10> , int_c<0> , my_fun<_1,_2> >::type sum; // error! Otherwise, it's more or less safe :). Aleksey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost