Re: [boost] filesystem library const usage

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-08-02 11:30:56

At 10:25 PM 8/1/2002, Darin Adler wrote:

 >On Thursday, August 1, 2002, at 05:18  PM, Beman Dawes wrote:
 >
 >> At 08:04 PM 8/1/2002, Glen Knowles wrote:
 >>> I believe begin() should return a const iterator, you then assign it
 >>> to a non-const iterator ("it" above) and then inc/dec the copy.
 >>
 >> I doubt users would find that attractive. You would have to cast away
 >> const.
 >
 >Not true. You can copy a const object into non-const variable. Consider
 >a function that returns const int. There's no problem assigning that to
 >an int variable.

I stand corrected.

 >You'd only have to cast away const if you were changing the type of the
 >object itself rather than copying its value.
 >
 >> Furthermore, the Standard Library container requirements, table 65,
 >> require that the return type of begin() be "iterator", not "const
 >> iterator".
 >
 >Definitely correct.
 >
 >> Again, I don't think the Filesystem Library is the place to try to
 >> solve wider iterator problems.
 >
 >I don't think this is really about wider iterator problems. The
 >argument you cite for making return values of type string be const
 >string does apply equally well to the iterators, in my opinion. But as
 >you say, this would be incompatible with the standard library container
 >requirements.

A path already isn't a container in the sense of meeting the standard 
library container requirements.  So that argument or mine was a bit of a 
red-herring.

Out of curiosity, I changed the begin() and end() returns to const. 
Horrors; the path regression test then produced 41 errors.  It is shot full 
of code like:

   BOOST_TEST( ++itr_ck.begin() == itr_ck.end() );

The correct code works fine:

   BOOST_TEST( next(itr_ck.begin()) == itr_ck.end() );

++itr_ck.begin() isn't just a theoretical portability problem, it could 
easily happen in practice if the implementation used a vector<> internally, 
and just used the vector's iterator type.  A perfectly valid, 
implementation, and a useful one for certain operating systems.

This is exactly the kind of portability problem I'd like to see the 
interface avoid.  I'm going to change the begin() and end() returns to 
const iterator.

Thanks to Mattias Flodin for suggesting this, to Glenn, Darin, Peter for 
clarifying the issues, and to Dave for mentioning boost::next() and 
prior().

--Beman