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

From: Glen Knowles (gknowles_at_[hidden])
Date: 2002-09-16 22:57:20

> From: David Abrahams [mailto:dave_at_[hidden]]
>
> > From: "Thomas Witt" <witt_at_[hidden]>
> > 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.
>
> Why not just store it in the policies object to begin with, and provide 
> an object factory (which takes a path) as many of the examples do?
>
>     make_directory_iterator(char const* path)
>     {
>         dir_it(some_base_object(), dir_it_policies(path));
>     }

I also implemented a directory iterator (with specialized directory walking
rules) using the iterator_adaptors and did it by using a std::string as the
base type that initialized the policy and was then just "ballast". I never
thought to consider an object factory, but of:

1. MyIter iter = make_special_iterator("start_directory");
2. MyIter iter("start_directory")

I prefer the syntax of the second. Especially for the "end" iterator where
it can simply be the default constructor in the second syntax. In my case I
was carrying so much state information that one more string didn't bother
me, but I see the argument.

Glen