dp::Iterator< Item > Class Template Referenceabstract

Definition of the Design Pattern Iterator interface. More...

#include <Iterator.hpp>

Inheritance diagram for dp::Iterator< Item >:

Public Types

typedef void(IteratorClient::* Method) (Item t)

Public Member Functions

virtual void first ()=0
virtual IteratorStatus next ()=0
virtual bool isDone ()=0
virtual Item currentItem ()=0
virtual void iterate (void *aClient, Method method)
- Public Member Functions inherited from dp::SmartPointer
virtual void use ()
virtual void forget ()

Additional Inherited Members

- Protected Member Functions inherited from dp::SmartPointer
 SmartPointer ()
virtual ~SmartPointer ()

Detailed Description

template<class Item>
class dp::Iterator< Item >

Definition of the Design Pattern Iterator interface.

Iteration is an important concept, which is specially true for PLAST whose core algorithm iterates over some seeds set. A very important point in PLAST parallelization is that the full seeds iterator can be split into several ones, each of them being iterated in a specific thread (and therefore on specific core if we have a multi-cores computer).

So the Iterator concept is here reified as a template class that knows how to iterate some set of objects.

Actually, the interface has two ways for iterating instances: 1- the 'classic' one in terms of Iterator Design Pattern (see first/next/isDone methods) 2- a callback way (see 'iterate' methods) where some client provides a callback that will be called for each object

There may be good reasons for using one way or another. For instance, the first one may be easier to use by clients (no extra method to be defined) but may be less efficient because more methods calls will be carried out.

Note that 'iterate' has great subclassing potentiality; by default, its implementation relies on first/isDone/next/currentItem methods and so can't be faster that the 'classic' way. But specific implementations of Iterator may implement 'iterate' directly by using inner state of the class, and so without call to first/isDone/next/currentItem methods.

Note that for optimization point of view, PLAST algorithm prefers to use the 'iterate' way with optimized implementations.

Sample of use:

dp::Iterator<MyType*>* it = new MyIterator ();
for (it->first(); ! it->isDone(); it->next() )
// retrieve the current item of some type
MyType* item = it->currentItem ();

A remark on the STL: the Standard Template Library provides also the iterator concept. For instance, one could write:

std::list<MyType*> l;
// we suppose here that we add some items to the list.
for (std::list<MyType*>::iterator it = l.begin(); it != l.end(); it++)
// retrieve the current item of some type
MyType* item = *it;

We can see the following differences with our own iterator.

  • the iteration loop with the STL needs to know the iterated list, through the beginning iterator 'l.begin()' and the ending iterator 'l.end()'. In our case, we don't have any reference of the iterated container, we can see only a reference on the iterator itself.
  • the iteration loop with the STL makes apparent the actual type of the container ('list' in the example), which is not the case for our iterator, where we can see only the type of the iterated items.
  • the STL iterators can only iterate contents of containers, ie. some items already in memory. Our iterator concept is more general because it can iterate items that it builds on the fly, without having the whole items mounted in memory. A typical use is the parsing of a huge FASTA database (say 8 GBytes for instance). With a STL iterator, we should have the whole sequences lying in some containers before iterating them; with our iterator, it is enough to know a sequence at a given time. Note however that clients of such iterators must not reference a sequence that is transient by nature. In such a case, clients have to copy, if needed, the iterated sequence for some local work.

In brief, our iterator encapsulates more information that the STL iterator, allows to iterate potential containers (versus actual containers) and may be easier to use.

Moreover, we can use our iterator as a basis for other ways for iteration. See dp::impl::IteratorGet

Member Typedef Documentation

template<class Item>
typedef void(IteratorClient::* dp::Iterator< Item >::Method) (Item t)

Define the prototype of the callback method (see 'iterate' method).

Member Function Documentation

template<class Item>
virtual void dp::Iterator< Item >::iterate ( void *  aClient,
Method  method 

Method for iterating items through a method of a client.

[in]aClient: client instance (as a void*) that will be called through the 'method' called.
[in]method: callback method

Reimplemented in database::impl::CompositeSequenceIterator, seed::impl::AbstractSeedIterator, algo::hits::common::AbstractPipeHitIterator, algo::hits::seed::SeedHitIterator, and algo::hits::seed::SeedHitIteratorCached.

The documentation for this class was generated from the following file: