Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at