Ben: the naming partial_permutation would be a very good idea. I like it. Am I correct that your (very cute!) idea would be extended to prev_ as follows: bool next_partial_permutation(first, middle, last) { reverse (middle, last); return next_permutation(first, last); } prev_partial_permutation ( { bool result = next_permutation(first, last); reverse (middle, last); return result; } That's all good, then. BTW, you *should* assume that the client has already sorted the range. In other words, garbage in, garbage out, and that's OK. There's not reason to penalize those who keep their ranges sorted. It simply needs to be documented as a Requirement: and given again as a Post-condition: (since the functions maintain the sorted range invariant). As for the other functions, I will send you my proposal soon... HB On Nov 12, 2007, at 8:52 PM, Ben Bear wrote:
2007/11/13, Hervé Brönnimann <hervebronnimann@mac.com>:
Ben, Giovanni: I've been giving some thought to this and I don't think that I'd want to propose next_permutation(first, middle, last) to the standard. It is easily achievable through next_combination (first, middle, last) then going over all the permutations via next_permutation(first, middle), in a loop. Granted, the order of the permutations is a bit different that way, but frankly nobody should care, the order is well specified (just not the lexicographic order on the permutations, but the lexicographic order on the underlying combination and if this combination is the same, the lexicographic order of the permutations), and it makes the would-be proposal a pure library extension -- so much easier to pass by the committee.
Another way, why do not we change the name? The std::permutation are actually full permutation, so we can call the new one "partial permutation".
Will this make more trouble? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/ listinfo.cgi/boost