[Home]STLAlgorithmExtensions/DesignRationale

BOOST WIKI | STLAlgorithmExtensions | RecentChanges | Preferences | Page List | Links List

Difference (from prior major revision) (minor diff, author diff)

Changed: 4c4
the tradeoffs between using an iterator adaptor or and algorithm
the tradeoffs between using an iterator adaptor or an algorithm

Added: 6a7
<pre>

Added: 30a32
</pre>

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.


BOOST WIKI | STLAlgorithmExtensions | RecentChanges | Preferences | Page List | Links List
Edit text of this page | View other revisions
Last edited August 19, 2006 11:30 am (diff)
Search:
Disclaimer: This site not officially maintained by Boost Developers