Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-07-26 11:04:46

Hash: SHA1

Dave, Jeremy,

On Friday 26 July 2002 17:07, Jeremy Siek wrote:
> On Fri, 26 Jul 2002, David Abrahams wrote:
> dave>
> dave> As a replacement for the existing iterator_adaptor? Do you really
> dave> want to drop "adaptor" from the name? It's not a "Policy builder"
> dave> pattern, after all...
> Well, iterator_adaptor really has two purposes: adapting and creating from
> scratch. It seems to me that the name "builder" encompasses both of these
> purposes better than "adaptor".

I think that Jeremys analisys regarding the different purposes is correct.
IMHO the naming problem can only be solved by answering the question what the
purpose of an iterator_xxx is. As stated earlier I do not feel totally happy
with the current design.

To me the biggest achievement of the current iterator_adaptor is the
definition of a minimum set of operations needed to implement a full fledged
iterator interface. This idea is so usefull that the scope for
iterator_adaptor widened from adapting iterators to creating iterators, and
thats where the naming problems starts.

To me there are two ways to look at iterator_adaptor. The way currently
represented in the documentation. It is called adaptor because it adapts the
behaviour of a given iterator using a policies class to describe the way the
adaption should be preformed. The other way is to view the iterator_adaptor
template as an interface adapter modelling the adapter pattern in the GoF
book. Where the policies really represent the concept of a LeanIterator(or
whatever you will call it). I think this view is more in line with the
purpose of creating iterators. The user implements a LeanIterator and the
library does the tedious work of implementing the full interface.

The policies class concept in the current implementation has a number of
problems. To me the worst are unsufficient encapsulation and distribution of
state. IIRC in the current design there is no way to prevent the user from
manipulating the underlying iterator. As a result class invariants can not be
guaranteed by the author of a specific iterator_adaptor. Today the state of
the iterator distributed between the iterator_adaptor and the policies. This
leads to no end of problems regarding comparison and const/non-const

I think that the adapter/LeanIterator view can be beneficial in overcoming
this problems. The adapter would only care about adapting the interface
whereas the LeanIterator would care about behaviour and state. Behavioural
adaption would be as easy as it was before simply implement a new
LeanIterator or derive from a supplied Adaptor<AdaptedIterator> that
implements the LeanIterator interface.

I was going to propose a adapter/LeanIterator implementation somewhen in the
future. I have a working prototype that I use happily for roughly half a year


- --Thomas

- --
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


Boost list run by bdawes at, gregod at, cpdaniel at, john at