Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: David Abrahams (dave_at_[hidden])
Date: 2008-11-21 21:51:32

on Fri Nov 21 2008, "Dave Handley" <dave-AT-dah.me.uk> wrote:

> <snip>
>>
>> I'll let Tomas answer for himself fully. But in short:
>>
>> You used to be able to call member functions on default-constructed
>> iterator_ranges, now you cannot. [Apologies for the hard-coded paths in the
>> following code]:
>>
>> ---
>>
>> //#include "c:/boost/boost_1_34_0/boost/range/iterator_range.hpp"
>> #include "c:/boost/boost_1_36_0/boost/range/iterator_range.hpp"
>>
>> #include <vector>
>> #include <iostream>
>> #include <cstddef>
>>
>> int main()
>> {
>>  boost::iterator_range< std::vector<int>::const_iterator>  r;
>>
>>  bool b1 = r.empty();        //returns true in 1.34,
>> //asserts in debug 1.35+, undefined
>> behaviour in release
>>  std::size_t b2 = r.size();  //returns 0 in 1.34   ,
>> //asserts in debug 1.35+, undefined
>> behaviour in release
>>
>>  std::cout << "\n\n" << b1 << b2 << "\n\n";
>> }
>>
>
> Furthermore, the following code changes have occured:
>
> boost::iterator_range<std::vector<int>::const_iterator> r;
> bool b1 = r.is_singular();  // returns true in 1.34 and debug 1.35.  Returns false in
> release 1.35

If singular means what I think it does(**) I don't think such a function
should exist in the public interface.  There is no test for a singular
pointer or its moral equivalent, an uninitialized int.

(**) well, probably with these kinds of fluctuations in semantics the
     meaning was never really well-understood by its author

> Look at this code (copied directly from boost::iterator_range 1.37):
>
>            bool is_singular() const
>            {
>                 #ifndef NDEBUG
>                 return singular;
>                 #else
>                 return false;
>                 #endif
>            }
>
> Taken from the iterator_range class.  IMHO this is broken, 

I think I'll probably agree with you, but I'd like it in general if
statements are accompanied by some rationale.  From here I can't be sure
_why_ you think it's broken.

> the functionality changes between debug and release in 1.35, 

Yeah, that's problematic.  Such changes should usually be restricted to
changes in the expression of undefined behavior.

> as well as changing from 1.34 to 1.35.  The assertions occur in
> virtually all the interface functions.

My guess is that they're Thorsten's attempt to avoid silent breakage.
Whether or not the attempt was well-executed is another matter, but I
can understand why he might have done it: he realized that the original
design was wrong, and rather than silently letting people get away with
using it in ways that were to become illegal, he detected the
newly-illegal usage in the only way possible, at runtime.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com