Is using ranges in c++ advisable at all?

Viewed 233

I find the traditional syntax of most c++ stl algorithms annoying; that using them is lengthy to write is only a small issue, but that they always need to operate on existing objects limits their composability considerably.

I was happy to see the advent of ranges in the stl; however, as of C++20, there are severe shortcomings: the support for this among different implementations of the standard library varies, and many things present in range-v3 did not make it into C++20, such as (to my great surprise), converting a view into a vector (which, for me, renders this all a bit useless if I cannot store the results of a computation in a vector).

On the other hand, using range-v3 also seems not ideal to me: it is poorly documented (and I don't agree that all things in there are self-explanatory), and, more severely, C++20-ideas of ranges differ from what range-v3 does, so I cannot just say, okay, let's stick with range-v3; that will become standard anyway at some time.

So, should I even use any of the two? Or is this all just not worth it, and by relying on std ranges or range-v3, making my code too difficult to maintain and port?

2 Answers

Is using ranges in c++ advisable at all?

Yes.

and many things present in range-v3 did not make it into C++20, such as (to my great surprise), converting a view into a vector

Yes. But std::ranges::to has been adopted by C++23, which is more powerful and works well with C++23's range version constructor of stl containers.

So, should I even use any of the two?

You should use the standard library <ranges>.

It contains several PR enhancements such as owning_view, redesigned split_view, and ongoing LWG fixes. In addition, C++23 brings not only more adapters such as join_with_view and zip_view, etc., but also more powerful features such as pipe support for user-defined range adaptors (P2387), and formatting ranges (P2286), etc. The only thing you have to do is wait for the compiler to implement it. You can refer to cppreference for the newest compiler support.

I recommend using range-v3 and not std::ranges. There are too many things missing (at least before c++23 is implemented) to make it worth using std::ranges at all.

On the other hand, using range-v3 also seems not ideal to me: it is poorly documented (and I don't agree that all things in there are self-explanatory),

It's easily enough to learn range-v3 from these supplementary materials https://www.walletfox.com/course/quickref_range_v3.php https://www.walletfox.com/course/examples_range_v3.php and you could always buy the book if you want more.

Also range-v3 is open source so you can let the source code be your documentation.

and, more severely, C++20-ideas of ranges differ from what range-v3 does, so I cannot just say, okay, let's stick with range-v3; that will become standard anyway at some time.

I doubt these changes will matter, much, the main problem is that range-v3 and std::ranges dont combine but changing the namespaces should be most of the effort porting range-v3 to std::ranges 23.

making my code too difficult to maintain

Code without ranges is too difficult. The amount of time I save by using range-v3 for everything is enormous, particularly the time taken ironing out the bugs in freshly written code, but also the time it takes to understand code you've written in the past, and then modify it. I think the only reason to not use range-v3 is to maintain the conventions of an existing codebase.

Related