Boost logo

Boost :

Subject: Re: [boost] combinations and permutations
From: BernardH (boost-dev.ml_at_[hidden])
Date: 2011-01-05 16:58:18


Howard Hinnant <howard.hinnant <at> gmail.com> writes:

>
> On Jan 5, 2011, at 7:20 AM, bernardH wrote:
>
> In my current code my algorithm is recursive:
> ...
>
> The problem is I can't return a compile-time constant because
>of the recursion.

I must be missing something, but I fail to see the problem :
couldn't you just use an
#define EARLY_EXIT(condition) \
    do{ \
      result_type const result(condition); \
      if(result) \
        return result; \
    }while(false) // to allow ;

with
    typedef typename result_of<
Function(typename
std::iterator_traits<BidirectionalIterator>::value_type)
>::type result_type;
?
Untested code (*blush*)
 @http://paste.debian.net/103845/

And if this doesn't work, you could always have two separate
implementations one for Callable returning void and one for
Callable returning bool and use enable_if on the result_type
to select the proper one, no ?

> To complicate things, in
> some of the algorithms I wrap the Function with
> an adaptor on the way down in order to fancier things like
> reversible_permutation.

If my solution is correct, I do (want to :) )believe that
it could be adapted.

>
>
> The answer might depend upon if we get an equally performant
> next_* going. If we do, then I don't think the
> functor should return a bool to break: instead the client
> should use next_*. If we don't, then putting in
> the break feature means, at least to me, that there is no
> reason to use the next_* variant since it is always
> slower (even if only by a little).

Agreed.
 
> Thanks for furthering these algorithms.

Thank *you* for your most excellent code.

Best Regards,
Bernard


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk