QStringView Diaries: Zero-Allocation String Splitting

Because a range is a pair of iterators and a coroutine is simply a convenient way to implement them.

Ranges are a (start, end) pair of iterators that support begin/end -- think of them like a subset of containers that just provide access to the iterators over them. They also support the end iterator being a different type to the sstart iterator, supporting things like sentinel iterators (e.g. null pointer checks).

The next standard library supports using the standard algorithms with ranges, so you can say things like `std::sort(v)` instead of `std::sort(v.begin(), v.end())`.

IIUC, views are ranges that can adapt the results of the underlying object without changing the contents of that object, such as a lower-case view, or a reversed view. These work by doing the lower-case conversion on dereference, or swapping the increment/decrement operations.

> Coroutines still seem overkill to me though.

Coroutines are a fantastic way to implement ranges, in particular when you need runtime polymorphism over the way your range is implemented

e.g. they allow you to have for instance :

    class foo { 
       public: 
          virtual coroutine_range_type<int> get_foobar_list() const = 0;
    };


    class foo_using_vector : public foo {
      coroutine_range_type<int> get_list() const override { 
        for(int val : impl) 
          co_yield impl;
      }
      std::vector<int> impl;
    };


    class foo_using_some_fixed_list : public foo {
      coroutine_range_type<int> get_list() const override { 
         co_yield 1;
         co_yield 1;
         co_yield 2;
         co_yield 3; // or for instance getting something through some OS API, etc...
      }
    };

and then use that like you would use any container-like type, in range-based for-loops, in actual ranges...