> From: David Abrahams [mailto:dave@boost-consulting.com]
>
> > From: "Thomas Witt" <witt@ive.uni-hannover.de>
> > 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