Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Dave Handley (dave_at_[hidden])
Date: 2008-11-22 02:12:35

Comments inlined:

<snip>
>>
>> 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.

Sorry if this wasn't clear - I patched in the code to follow my description 
of why I thought it was broken - debug and release doing something 
completely different.

>
>> 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.

Newly illegal usage should always be documented as such - and in this 
instance I'm not convinced it was.

Dave