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