c++-gtk-utils
|
An iterator class providing a lazy integer range over a virtual container. More...
#include <c++-gtk-utils/parallel.h>
Public Types | |
typedef int | value_type |
typedef int | reference |
typedef void | pointer |
typedef int | difference_type |
typedef std::random_access_iterator_tag | iterator_category |
Public Member Functions | |
IntIter (value_type val_=0) noexcept | |
IntIter (const IntIter &)=default | |
IntIter & | operator= (const IntIter &)=default |
IntIter & | operator++ () noexcept |
IntIter | operator++ (int) noexcept |
IntIter & | operator-- () noexcept |
IntIter | operator-- (int) noexcept |
IntIter & | operator+= (difference_type n) noexcept |
IntIter & | operator-= (difference_type n) noexcept |
reference | operator[] (difference_type n) const noexcept |
reference | operator* () const noexcept |
An iterator class providing a lazy integer range over a virtual container.
This class acts as an iterator which iterates over a range of integers lazily, as if over a virtual container of incrementing ints constructed using std::iota. It is principally intended for use in constructing parallel for loops using Cgu::Thread::parallel_for_each() or Cgu::Thread::parallel_transform(), which is why it is in the c++-gtk-utils/parallel.h header, but it can be used whenever a lazy range of integers is required.
It behaves as a random access iterator to const int, and has the normal increment, decrement and other random access functions. When used with Cgu::Thread::parallel_for_each() and Cgu::Thread::parallel_transform(), because it acts as an iterator to const int, the callable object passed to those functions must take an int or const int& argument. Any IntIter object compares equal to any other IntIter object which at the time in question references the same int value, so it can be used as the beginning iterator or end iterator of a range for a standard algorithm; and one IntIter object is less than another IntIter object if it references an int value less than the other, and so on as regards the other comparison operators.
Here is an example of its use with Cgu::Thread::parallel_transform(), as a parallelized equivalent of a for loop which increments a count integer on each iteration through the loop. In this example, the count integer, as incremented on each iteration, is squared and the result stored in a std::vector object (in practice you would not want to use this construction for such a trivial case as it would be slower than the single threaded version - it is for use where some significant work is done in the for loop, here represented by the lambda expression):
Although unlikely to be useful very often, the iterator can count backwards using std::reverse_iterator:
Since 2.0.27 and 2.2.10.
typedef int Cgu::IntIter::difference_type |
typedef std::random_access_iterator_tag Cgu::IntIter::iterator_category |
typedef void Cgu::IntIter::pointer |
typedef int Cgu::IntIter::reference |
typedef int Cgu::IntIter::value_type |
|
inlineexplicitnoexcept |
This constructor acts as both a default constructor and an initializing constructor. It does not throw.
Since 2.0.27 and 2.2.10.
|
default |
The copy constructor does not throw.
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The dereferencing operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread and one calls a non-const method, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The pre-increment operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The post-increment operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
This operator adds the value of the argument to the integer value currently represented by the iterator. It does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The pre-decrement operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The post-decrement operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
This operator subtracts the value of the argument from the integer value currently represented by the iterator. It does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
The copy assignment operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.
|
inlinenoexcept |
The offset dereferencing operator does not throw. No locking is carried out, so if the iterator is accessed in more than one thread and one calls a non-const method, the user must provide synchronization (but Cgu::Thread::parallel_for_each(), Cgu::Thread::parallel_for_each_partial(), Cgu::Thread::parallel_transform() and Cgu::Thread::parallel_transform_partial() only access source and destination iterators in the thread which calls the functions, so use of an IntIter object only by one of those functions does not require synchronization).
Since 2.0.27 and 2.2.10.