STLAlgorithmExtensions/DesignRationale

Iterator Adaptors vs. Algorithms

The following was a discussion on the Boost email list about the tradeoffs between using an iterator adaptor or an algorithm to carry out a task like the one described by STLAlgorithmExtensions/PermuteAlgorithm.

toon.k> As for the permutation-algorithm : there is already a
toon.k> permutation_iterator adaptor in Boost (1.26)
toon.k> (inside the iterator_adaptor library).

jsiek> Sure, and one could implement the permute function in terms of the
jsiek> iterator adaptor, but I think it is still useful to have the algorithm
jsiek> since it is more convenient.

toon.k> I agree for the inplace permutation.
toon.k> The other one is totally overlapping AFAICS.

jsiek> Sure, but the permute_copy() is shorter to type, and easier for novices to
jsiek> find and understand.

toon.k> to get philosophical : where's the border between
toon.k> algorithm and iterator.

jsiek> The iterator approach can be more flexible and general since the users
jsiek> decides when and how to "pull" values, but it is a bit harder to
jsiek> understand, and more verbose to use. Also, the iterator approach is only
jsiek> applicable when you don't need very much state to perform the operation
jsiek> (unlike the inplace permute). I think it makes sense to provide both
jsiek> approaches, since they cater to different usage situations.