Boost logo

Boost :

From: Thomas Witt (witt_at_[hidden])
Date: 2002-09-15 02:05:24


On Sunday 15 September 2002 00:39, David Abrahams wrote:
> Why?
> Why not just make directory_iterator a typedef for an iterator_adaptor?
> Does it need additional interface beyond that of a standard iterator?

In a way, yes. As I tried to explain in my previous posting it needs a ctor
that takes a path. For most of the stdlib iterators ctors aren't really an
issue, as the container classes act as iterator factories. This is different
for directory_iterator. So we have to provide the iterator interface _and_
customized ctors. Thats why I said iterator_adaptor is not really well

With iterator_adaptor only a ctor taken the base_type is provided. As I tried
to show in my code example there is a way to use iterator_adaptor and have
the desired ctor, but I consider this solution a hack. In order to have the
desired ctor(directory_iterator(path const&)) I have made path the base type.
All iterator state is moved in the policies object and the base_type object is
only used during initialization. After the initialization the base_type object
is just unneccessary ballast.

> If so, I think it'll have to wait for our new iterator_adaptor design (I
> hope sometime early November).

I wasn't trying to say come on guys fix iterator_adaptors. I just think this
is a new use-case that makes making iterator_adaptor derivable a worthy goal.
I would be very interested in discussing ideas regarding iterator_adaptor.


Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: +49(0) 511 762 - 4273, fax: +49(0) 511 762-3001

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