Re: [boost] Is Boost.Range broken?

Subject: Re: [boost] Is Boost.Range broken?
From: Pete Bartlett (pete_at_[hidden])
Date: 2008-11-21 18:59:14

>on Fri Nov 21 2008, Tomas Puverle <Tomas.Puverle-AT-morganstanley.com>
>wrote:

>> I decided to split off this part of another thread to try to get a
>consensus on
>> the changes that occurred in Boost.Range with boost 1.35.  The background
>is
>> discussed elsewhere.  What I'd like to do here is to come to an agreement
>with
>> Thorsten and other developers on the following issues:
>>
>> 1) Is the change in the behaviour of Boost.Range in fact a defect?
>> 2) What should be done about it?
>>
>> Here are the reasons why I think Boost.Range is broken:

>I think you're assuming way too much about people's familiarity with the
>problems.  The things you are saying sound serious, but I certainly
>don't know enough about the way Range used to work and the nature of the
>change to evaluate most of what you wrote here.  Please lay out,
>specifically, how things used to work and how they work now.

>Thanks,

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