Custom iterators, creation

[Technocrat]

The STL and Boost contain a few special standalone iterators. They don't iterator over containers, rather they perform a special function. Those containers are of input_iterator and output_iterator categories and include std::ostream_iterator (wonderful for copying an array to a stream), std::istream_iterator (the reverse), std::back_insert_iterator (append everything to the back of a container) as well as the relatives std::insert_iterator and std::front_insert_iterator and boost::filesystem::directory_iterator (iterate over the files of a directory).

All these iterators aren't obtained by any begin() and end() functions, but created using constructors. For example, an ostream_iterator is created by passing a stream and a separation string:

std::copy(vec.begin(), vec.end(), std::ostream_iterator<std::string>(std::cout, "\n"));

For input iterators (those that can be read from), the "end" iterators are created by passing no arguments to the constructor:

std::vector<int> vec((std::istream_iterator<int>(std::cin)), std::isteam_iterator<int>());

See also Item #6 in Effective STL for the exact syntax of this call.


So far, so good.

I've written three input iterators myself. One iterates over the drives (a:, c:, d:, ...). The second over the network shares. The third over both by concatenating the two.

The problem is, there isn't anything to initialize. All iterators have system-fixed iteration ranges and thus don't need to be passed any. Right now I have the default constructor creating a start iterator and a static method called end creating the end iterator (via a call to a private constructor that takes a dummy int argument).

However, it doesn't feel quite right. Anybody got a better idea? I want this code to be perfect, I might submit it to Boost.

int index = 1;
for(root_iterator it, end(root_iterator::end()); it != end; ++it) {
	cout << index++ << ": ";
	cout << it->string() << endl;
}

[galathaea]

What concept are you using for the drive / network system container? At work I use a singleton manager interface for the file system, since it seems natural to model the file system as a singleton container in my circumstance. There are a set of functions used for exposing iterators to various locations, and iterators are never created except through these functions (so that only the copy ctor need be exposed to the public), and construction occurs privately through an identifier for a particular location (in my case, I just use a std::wstring for the path). Now in your situation, it would seem that a similar idea is possible. You could choose to expose the wstring ctor if you choose, but the main point is that the iterators could still be done through the interface to the file manager. The stream iterators by the standard library use the particular stream as a ctor argument, which is important because there are many different streams such an iterator might walk around through and this decoupling is useful, but I believe a file system is fairly soundly a singleton container which can manage its iterator creation as robustly as any other technique.

Just some thoughts!

[CornedBee]

The whole thing is based on the Boost filesystem library. As there is no manager object (singleton or not) in this library, I don't want to create one. I simply want to have standalone iterators that provide starting points for directory iterators.

All my interators are input_iterator category of course.

[Technocrat]

This is cornedbee's project, I just posted the question for him, if you cannot tell.