我可以在没有底层容器的情况下使用std :: upper_bound吗？

Question

I have a range of integers [start, end] and a non-decreasing monotonic function f(i) . So conceptually, I have a non-decreasing sequence [f(start), f(start + 1), .. , f(end)] . Can I use std::upper_bound on that sequence to find the first element i in the range that holds f(i) > some_value ?

Conceptually, I'd like something like this:

std::upper_bound(start, end + 1, some_value, [&](int lhs, int rhs) { 
    return f(lhs) < f(rhs);
});

But this doesn't compile because start and end + 1 do not meet the requirements of forward iterators .

Answer 1

The short answer is yes, since std::upper_bound works on iterators, not on containers. But iterators themselves are instances of corresponding class (for example, std::vector<int>::iterator or whatnot).

If you construct some specific class that will meet the requirements of ForwardIterator not being actually bound to some sort of container, while still meaning something (for example, if you want to generate your sequence procedurally), it should work just fine.

Note that simple integer will not do the trick. On the other hand, a class, whose objects hold the value of your function for a particular argument value (with some additional batteries), will.

Answer 2

There are basically two answers:
Would it work by the standard or would it work with all practical implementations of the STL?

By the standard, as TC pointed out already, there are some strict requirements on iterators, especially that *it has to return a (possibly const) reference to value_type (which we would satisfy by returning the reference to a member of the iterator), but we also need that for it1 == it2 , *it1 and *it2 are references bound to the same object, which is only possible if we have a distinct object for every number in the range.

If you want to do use this idea in practice, I don't believe any implementation of std::upper_bound or similar methods actually relies on this reference equality, so you could just use a class that encapsulates an integer as an iterator, only overloading the necessary methods . As far as I can see, boost::irange fulfills these requirements

As you can see, this is not strictly standard-compliant, but I see no reason why any implementation of binary search should rely on such strong requirements for the iterator, if the underlying 'storage' is const anyway.

Answer 3

No, not practically, but yes in practice, but no if you want to be practical.

No

upper_bound requires ForwardIterator . ForwardIterator requires that * returns an actual reference, and that if two iterators are equal then they refer to the same object.

Not practically

For a container-less iterator, this requires an insanely complex iterator that caches the values it returns in a shared global map of some kind. To make it half practical, note that the iterator requirements say very little about the lifetime of said reference; so you'd want to reference count and destroy said values as the iterators in question cease to exist.

Such a solution requires synchronization, global state, and is significantly more expensive and complex than something like boost::integer_range . No sane person would write this except as an exercise demonstrating why the standard needs to be fixed.

But yes in practice

No sane implementation of upper_bound actually requires that the iterators in question are full-scale forward iterators, barring one that does full concept-checks to validate against the standard (and not against what the actual algorithm needs). Input iterators with stability on the values returned almost certainly does it. There is no such concept in the C++ standard, and forward iterator is the weakest iterator category in the standard that satifies it.

This problem, of effectively demanding iterators be backed by containers, is a flaw in the standard in my opinion. Container-free iterators are powerful and useful, except they rarely technically work in standard containers.

Adding new iterator categories has proved problematic, because there is little way to do it without breaking existing code. They looked into it for contiguous iterators, and wrote it off as impractical (I don't know all the details of what they tried).

Adding new iterator concepts that are not backed by tags is more possible, but probably will have to wait until concepts are part of the C++ language and not just the standard; then experimenting with adding new concepts becomes something you can specify in C++ instead of in standardese, which makes it far easier.

But no if you want to be practical

This does, however, result in an ill-formed program, no diagnostic required. So consider if it is worth it; it may actually be easier to reimplement upper_bound than maintain a program whose every excution is undefined behavior, and every compile at the mercy of a compiler upgrade.