boost::range_iterators limitation for components

[NoAntzWk]

Hi,

I am using the development version r45 on Windows and the Boost
library v1.44.

I have troubles using boost::iterator_range<Iterator> for uri's
components (aka: scheme, userinfo, host, port, path, query, fragment).
When I try to access to these iterators an exception happens when the
uri's query part is not available. Sample:

uri::components<string::const_iterator> c;
uri::grammar<string::const_iterator> g(c);
std::string query (c.query.begin(), c.query.end()); //
Exception raises accessing to begin() and end() (iterators are NULL)

The implementation of iterator_range in newer boost library versions
has changed and an exception raises when calling to the empty(),
size(), begin() and end() methods when the range_iterators are NULL.

Any suggestions?

Best regards.

[NoAntzWk]

Hi,

Well, the issue with the "boost::iterator_range" it happens in debug
mode. I have solved it thus:

#ifdef _DEBUG
#define _HAS_ITERATOR_DEBUGGING 0
#endif

#include <string>
#include <uri/grammar.hpp>

....

Best regards.

[Braden McDaniel]

[and...]

> Well, the issue with the "boost::iterator_range" it happens in debug
> mode. I have solved it thus:
>
> #ifdef _DEBUG
> #define _HAS_ITERATOR_DEBUGGING 0
> #endif
>
> #include <string>
> #include <uri/grammar.hpp>

This actually has nothing to do with boost::iterator_range;
_HAS_ITERATOR_DEBUGGING is a symbol used by your (Microsoft) stdlib
implementation.

According to

http://www.boost.org/doc/libs/1_45_0/libs/range/doc/html/range/reference/utilities/iterator_range.html

"…if one creates a default constructed iterator_range, then one can
still call all its member functions."

But that doesn't mean that the member functions are guaranteed to return
valid iterators. And when one is dealing with a default-constructed
iterator_range, I don't see how they could (return valid iterators). So
the exception is thrown when you try to dereference one of the returned
(invalid) iterators.

What happens if you test iterator_range::empty first? The
iterator_range documentation doesn't come out and say that empty is
guaranteed to return "true" for a default-constructed iterator_range;
but the bit I quoted above is very near to that. That is, returning
"false" in this case would be silly; and doing something that causes the
underlying stdlib to throw would be inconsistent with the stated
guarantee.

--
Braden McDaniel <bra...@endoframe.com>