Compilation error caused by FeatureBase::end() of type `nullptr_t`

[byjtew]

Hello !

Tested on .gol files generated from .osm.pbf (switzerland and colorado) using a simple gol build command. I can provide them if necessary.

To reproduce:

#include <geodesk/geodesk.h>
#include <algorithm>

using namespace geodesk;

int main(int argc, char** argv)
{
    if (argc < 2)
    {
        std::cerr << "Usage: " << argv[0] << " <path/to/file.gol>" << std::endl;
        std::abort();
    }

    Features world(argv[1]);

    // Basic example, more generally any STL algorithm (including ranges namespace-d) will fail to compile.
    bool unused = std::any_of(world.begin(), world.end(), [](const auto& each) { return false; });

    return 0;
}

While I understand the convenience of using nullptr_t it actually forbids usage of range based functions like STLs 😕

Environments tested:

• Windows 10 & MSVC 14.43.34808
• macOS 15.3.2 & Apple clang 17.0.0

[clarisma]

This one is tricky, because FeatureIterator is not a classic STL iterator in the sense that it does not actually point to the features being iterated (so you cannot "go back" to a specific iterator). Features is not container class, it is merely a lightweight descriptor of a query, and FeatureIterator simply peels off the features as they are returned by the Query Engine. This enables range-based for loops, but other range-based STL operations are not supported.

The reason for this is not merely the null-pointer sentinel (We could switch to a sentinel class, since libgeodesk now requires C++20), but also the fact that FeatureIterator objects are not copyable.

More likely, we're going to support the most common STL operations directly in Features: any(), all(), none(), forEach() etc. -- these could then also implement optimizations that the generic STL functions would not be able to perform. Are there any additional ones that should be supported?

To access the full set of range-based ops (such as std::sort), you would need to turn Features into a std::vector, either by assigning or via addTo().

[byjtew]

This one is tricky, because FeatureIterator is not a classic STL iterator in the sense that it does not actually point to the features being iterated (so you cannot "go back" to a specific iterator). Features is not container class, it is merely a lightweight descriptor of a query, and FeatureIterator simply peels off the features as they are returned by the Query Engine. This enables range-based for loops, but other range-based STL operations are not supported.

Yes I understand that, a cheap alternative would be to wrap it in a boost iterator (or custom) that keeps the current implementation inside but exposing same types for begin() and end().

More likely, we're going to support the most common STL operations directly in Features: any(), all(), none(), forEach() etc. -- these could then also implement optimizations that the generic STL functions would not be able to perform. Are there any additional ones that should be supported?

Completely in favour of that.
The method count(lambda) would be nice too.

To access the full set of range-based ops (such as std::sort), you would need to turn Features into a std::vector, either by assigning or via addTo().

Yes that's perfectly fine as is imo.

[clarisma]

Just remembered, you can also use Features::filter with a predicate:

bool hasAny = !features.filter([](const auto& each) { return false; }).isEmpty();