On Fri, Jul 13, 2012 at 7:36 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Friday 13 July 2012 07:16:36 Beman Dawes wrote:
On Thu, Jul 12, 2012 at 1:39 PM, Nathan Ridge <zeratul976@hotmail.com> wrote:
I'm a little surprised to see a function that returns a range named "directory_iterator".
Other Boost libraries, such as Boost.Iterator and Boost.Range, distinguish between the concepts of an iterator, which denotes a single position in a range, and a range, which is defined by iterators at is beginning and its end.
directory_iterator is like std::istream_iterator in that a directory_iterator object identifies the end of a range simply by being equal to directory_iterator(). Thus these iterators are a little odd in that they self-identify both the beginning and the end of the range. So there is no real distinction between an my_iterator and begin(my_iterator). The only reason the function is there is to meet the range-based for statement requirements. Ditto for BOOST_FOREACH range helper functions.
There may be no distinction between my_iterator and begin(my_iterator) but there is between my_iterator and end(my_iterator). And since range-based for iterates, well, through a range, it is odd to see an iterator there, even though the range can be deduced from it.
Have you considered naming the function "directory_range" to be consistent with other Boost libraries?
"directory_iterator" is the constructor for class directory_iterator. I'm happy with that as a name since it identifies the primary use of the class.
I'm happy with the "directory_iterator" name for an iterator. But not for something acting as a range as well. I'd like to see a distinct range class (probably, a typedef for iterator_range<directory_iterator>) which can be used with the range-based loops naturally, instead of abusing begin() and end(). And make_directory_range(directory_iterator) function would be welcome as well.
I don't see any abuse of begin() and end(). They were put in the core language's list of ways to enable range-base for so that there would be no need to add the complication of a separate class plus a make_x_range function to handle cases like this. Unless I'm missing something, adding wrappers the user must use increases complexity and reduces teachability without adding additional functionality. The beauty of begin/end free functions is that the user doesn't even have to know they exist - range-based for "just works". --Beman