Boost logo

Boost :

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.


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