Bruno Lalande wrote:

There is also a no-parameter qend() which return a special end_query_iterator which may be compared with arbitrary iterator returned by qbegin() to check if the query has ended. But since it has different type it can't be used in STL algorithms like std::copy().

This sounds a bit unusual. What I've seen done so far is that the same iterator type is used and it simply as a no parameter constructor, and flags itself as end-iterator/default-constructed if constructed this way. Was it really an issue to do like that?

Otherwise, sounds like a useful addition, thanks for that.

The problem is that the Predicates are stored inside the iterator which means that they're a part of the iterator type. To construct the end iterator of the same type the Predicates must also be known. Additionally, the type of this raw iterator can't be defined in the container because it depends on the Predicates expression. And yes a default-constructed iterator is an end iterator. These iterators can be obtained by:

tree.qbegin(/*predicates*/) and tree.qend(/*predicates*/)

For convinience I've added tree.qend() but it returns an iterator of different type.
To allow less experienced users to use those iterators e.g. in a for loop I've defined a type-erased const_iterator_type.

I also think that this is quite complicated and if we found a better solution I'd gladly change the existing one.

One possible solution would be the implementation of qbegin() and qend() returning type-erased iterators and e.g. some other methods like qbegin_xxx() and qend_xxx() returning raw Predicates-dependent iterators.

Or maybe do you have some other ideas?

One thing you should probably know is that those raw Predicates-dependent iterators are fat iterators, tree traversing stack is stored inside so they're quite big.