Re: [boost] Filesystem Library: Final version for Formal Review

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

Dave,

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 
suited.

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. 

--Thomas

-- 
Dipl.-Ing. Thomas Witt
Institut fuer Verkehrswesen, Eisenbahnbau und -betrieb, Universitaet Hannover
voice: [phone] - 4273, fax: [phone]
http://www.ive.uni-hannover.de