Question

I’m using Boost.Range to pass around some data and a container class for this data. The data is loaded in a different thread and may in some cases not be ready yet. In this case the container is initialized with the default iterator_range, hence containing singular iterators. I’m doing assignments and copying of the data containers (hence the iterator_ranges). However, the iterator_range copy constructor calls begin() and end() which will assert when the original is singular. Therefor, it is not possible to copy an empty data container.

Is there any way to avoid this limitation?

Why is this limitation been implemented? The following works just fine, shouldn’t ranges behave similarly?

typedef std::vector<int>::iterator iterator;
iterator it; // Singular
iterator it2 = it; // Works

boost::iterator_range<iterator> range; // Singular
boost::iterator_range<iterator> range2 = range; // Asserts in debug, but why?

Answer 1

If by “works”, you mean “it does not blow up with my current compiler version and invocation options”, then yes, assigning a singular iterator might “work”.
Actually, the code

typedef std::vector<int>::iterator iterator;
iterator it; // Singular
iterator it2 = it; // Works

results in undefined behaviour, so you are up to the whims of your compiler for what may happen.

The C++ standard has this to say about it (section [lib.iterator.requirements]/5):

[…] Results of most expressions are undefined for singular values; the only exception is an assignment of a non-singular value to an iterator that holds a singular value. In this case the singular value is overwritten the same way as any other value. Dereferenceable and past-the-end values are always non-singular.

So, in the end ranges do work similar to single iterators. It just doesn’t work the way you would like.
I think the best way is to use an empty range (explicitly constructed with to non-singular iterators) when the data is not yet ready, instead of a singular range.