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.
Then, what about next_permutation(first, middle, last, comp)? Don't propose it too? next_permutation(first, middle, last) is easy to be implemented: bool next_permutation(first, middle, last) { // actually, sort only need once, that's what init()/adjust() does sort (middle, last); reverse (middle, last); return next_permutation(first, last); } If only propose combination's functions, there's eight functions: init_combination(first, middle, last, min); init_combination(first, middle, last, min, comp); adjust_combination(first, middle, last); adjust_combination(first, middle, last, comp); next_combination(first, middle, last); next_combination(first, middle, last, comp); prev_combination(first, middle, last); prev_combiantion(first, middle, last, comp); I think that, whether the init() and adjust() can be removed, but leave the initialization to the callers, then only four functions is needed. I think this is not a good idea.