Re: [boost] [filesystem] C++11 range-based for statement and BOOST_FOREACH support

Subject: Re: [boost] [filesystem] C++11 range-based for statement and BOOST_FOREACH support
From: Beman Dawes (bdawes_at_[hidden])
Date: 2012-07-13 07:55:13

On Fri, Jul 13, 2012 at 7:36 AM, Andrey Semashev
<andrey.semashev_at_[hidden]> wrote:
> On Friday 13 July 2012 07:16:36 Beman Dawes wrote:
>> On Thu, Jul 12, 2012 at 1:39 PM, Nathan Ridge <zeratul976_at_[hidden]>
> 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