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