range-v3 | Range library for C++14/17/20 , basis for C++20 's std : :ranges | Hashing library

In the following code, auto [i, e] and auto&& [i, ee] both bind std::pair rather than std::pair. Could some explain how could have known this without testing empirically? I assume it's the range-v3 implementation. Is there a case where you would want to use auto&& rather than auto?

I am trying to convert a vector to a string and join with C++20(MSVC on visual studio 19 v142, c++latest).

C++20 ranges::sort supports projections, and that is great, but I want to do stuff that is more complex, in particular sort on result of function that operates on projected member.

For function call I tried the transform and then sort that view, but C++20 sort seems to not work on views, this answer explains why(for range-v3).

In other words can I write this without using a lambda/functor?

I'm using range-v3 by Eric Niebler and using the ranges::views::group_by function.

In the documentation for group_by it says: "Given a source range and a binary predicate, return a range of ranges where each range contains contiguous elements from the source range such that the following condition holds: for each element in the range apart from the first, when that element and the first element are passed to the binary predicate, the result is true. In essence, views::group_by groups contiguous elements together with a binary predicate."

So, it returns a range and ranges. My question is how do I access the range of ranges individually? I've tried all the using ways of accessing ranges: p[0].first, p.at(0).first, p.begin.first etc. but no joy.

I have the following code:

I've been trying to understand the Range-v3 join documentation but I'll be honest, I don't understand it. And I've not been able to find any relevant examples either.

Could someone show me how to create a joined view of two deque vectors please. I've already tried these methods but to no avail.

I have a pair of iterator, and I would like to use ranges::views::filter(some_predicate) on it (with the pipe operator). AFAIU I should first convert my pair of iterator into a view. I tried to use ranges::subrange(first, last) to do so, but I’m getting horrible error messages.

Note1: I’m using C++14 and range-v3 version 0.9.1 (the last version compatible with gcc-5.5). If the solution differs when using C++17/20 and/or when using C++20 std::ranges, I’m also interested to know what changed.

Note2: I find the documentation of range-v3 severely lacking, so I’m using cppreference.com. If you know a better documentation, I’m very interested.

EDIT:

In my real code, I’m wrapping a java-style legacy iterator (that has a next() method instead of operator++/operator*. I’m wrapping them in a C++-compatible wrapper. Then I tried to convert that wrapper into a view, and finally filter it. I reproduce a minimal example on godbolt. This use iterator_range as suggested, but it still doesn’t compile (see the second edit below).

I'm trying to link OpenGL to an application for Windows (building on Windows).

I'm using Conan as package manager, CMake for building and MSVC as compiler (and CLion as IDE).

The program compiles, but I have linker errors, for what I believe to be extension functions in OpenGL:

I found that c++20 ranges::basic_istream_view is slightly different from the range-v3 version.

The most important difference is that the std::ranges::basic_istream_view does not cache its begin(), so that each begin()s will return the next iterator with the value that has been read (godbolt):

Here in a simple pipeline of views adaptors, there is the gen function called to generate a sequence of values (using an internal state) and then a filter on it.

What is surprising and counterintuitive (at least for me) is the fact that the generator function is called twice at each iteration, so that the next check on the same filter fails (the filtered value is not reused in the pipeline).

Do you have an idea if this is the correct expected behavior (and why)?

Tested with libstdc++ in GCC 10.3, 11.1 & trunk (code) and range-v3 with GCC & clang (code).