[Home]STLAlgorithmExtensions/IotaAlgorithm

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

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

Added: 74a75,95

I think there is a better way to fill the container with subsequent numbers.

Following the [interval and integer iterator], you can
define it as:

sktl::ivi( 0, 30 ).copy_back( v );

It allows also to give a sequence step as:

sktl::ivs<3>( 3, 18 ).copy_back( v );

The ivi function creates an interval of integer iterators with step=1. I think the integer_iterator class can
be still genericized (and called, let's say, sequence_iterator) and the `int' type, on which it's based replaced
with a parameter. This however would require resignation from the `tStep' parameter if the value type is not int.



Let's not forget why there are algorithms in the first place: They're are almost always better because they tell you what they do up-front, while using a counting iterator is only marginally better (or even worse) than a for loop: The latter two are constructs that need to be parsed by the reader of the code anew each time. An algorithm makes it absolutely clear what's going on on the first look.

So if you can do something as an algorithm or as an iterator adapter, prefer the algorithm, and provide the adaptor as a goody.
--Marc Mutz

The [iota()] function from the SGI STL is a good example of a small but useful algorithm that would fit nicely in the Boost.Algorithm library.

This function fills the range [first,last) with values generated by incrementing the value parameter. This is useful for filling an array with the integers 0...N-1.

 
 template <class ForwardIterator, class T>
 void iota(ForwardIterator first, ForwardIterator last, T value)
 {
   while (first != last)
     *first++ = value++;
 }
 


Would it not be less demanding to require only pre-increament, and more efficient to use it?

 
 template <class ForwardIterator, class T>
 void iota(ForwardIterator first, ForwardIterator last, T value)
 {
   while (first != last) {
     *first = value;
     ++ first;
     ++ value;
   }
 }
 

This avoids the creation of temporaries.

People/JeremySiek noted a typo in my original draft of iota, and also wrote: "Some compilers can get rid of the temporaries in some situations, but perhaps it is better not to rely on that."

--People/JamesDennett


This is a generate style of algorithm. It seems that the generate_n style would also be useful to support output iterators such as the insertion iterators.

 
 template <class OutputIterator, class Size, class T>
 void iota_n (OutputIterator first, Size n, T value)
 {
   for (; n > 0; -- n)
     {
     *first = value;
     ++ first;
     ++ value;
     }
 }
 

Another possibility would be to supply function types for use with the existing generate algorithms.

 
 template <class T>
 class Iota {
   public :
     Iota (T const& v) : value(v) { }
     T operator() () { return value ++; }
   private :
     T value;
 };

 generate(v.begin(), v.end(), Iota<int>(0));
 generate_n(back_inserter(v), 30, Iota<int>(0));
 

--John Potter


The same effect can already be achieved in Boost using [Counting Iterator]. So is it worth adding an algorithm as well?

--Alan Stokes

I think there is a better way to fill the container with subsequent numbers.

Following the [interval and integer iterator], you can define it as:

sktl::ivi( 0, 30 ).copy_back( v );

It allows also to give a sequence step as:

sktl::ivs<3>( 3, 18 ).copy_back( v );

The ivi function creates an interval of integer iterators with step=1. I think the integer_iterator class can be still genericized (and called, let's say, sequence_iterator) and the `int' type, on which it's based replaced with a parameter. This however would require resignation from the `tStep' parameter if the value type is not int.


Let's not forget why there are algorithms in the first place: They're are almost always better because they tell you what they do up-front, while using a counting iterator is only marginally better (or even worse) than a for loop: The latter two are constructs that need to be parsed by the reader of the code anew each time. An algorithm makes it absolutely clear what's going on on the first look.

So if you can do something as an algorithm or as an iterator adapter, prefer the algorithm, and provide the adaptor as a goody. --Marc Mutz


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