BOOST WIKI | STLAlgorithmExtensions | RecentChanges | Preferences | Page List | Links List
Difference (from prior major revision)
(minor diff, author diff)
the tradeoffs between using an iterator adaptor or and algorithm|
the tradeoffs between using an iterator adaptor or an algorithm|
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.
Disclaimer: This site not officially maintained by Boost Developers