You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was watching your latest talk about the algorithms/range adaptors that C++23 introduces. I'm excited to see you advertising this "sequential programming" style! I'm already a big fan of ranges, but mostly use the range-v3 library at the moment.
In the talk, you mention at around 1:13h that you could not come up with a more elegant way of simplifying the Sushi-for-Two problem using range-v3. You mostly criticize the issue that one cannot pipe into variadiac templates (like zip_with and concat). I fully agree that the Circle compiler has a neat solution for the general pipeline operator. However, I still believe that you can make the example a bit more elegant with "plain" range-v3 (see a full example in compiler explorer). I'm eager to hear what you think about my approach 🙂
Make a custom pairwise_transform adaptor
You have to introduce the temporary variables indices and deltas because you need to pipe them twice into the zip_with range adaptor. However, you could simply make a custom range adaptor, i.e., the pairwise_transform from C++23. Importantly, I make use of the make_pipeable helper that not too many people utilize. While this does not solve the underlying problem that one cannot pipe into variadic templates, in your example you could get rid of the temporary variables.
These adaptors solve the "nonlinearity" issue with concat. I, personally, hated that concat could not be piped into and it really breaks the flow of reading the code. Hence, I made myself the following two neat helpers that solved most of my problems. Of course these can be extended to appending/prepending ranges instead of single elements.
// Adds an element to the beginning of a range.template <typename Rng, typename T>
autoprepend(Rng&& rng, T t) {
returnrv::concat(rv::single(t), rng);
}
template <typename T>
autoprepend(T t) {
returnranges::make_pipeable([t](auto&& rng) { returnprepend(rng, t); });
}
// Adds an element to the end of a range.template <typename Rng, typename T>
autoappend(Rng&& rng, T t) {
returnrv::concat(rng, rv::single(t));
}
template <typename T>
autoappend(T t) {
returnranges::make_pipeable([t](auto&& rng) { returnappend(rng, t); });
Cheers and kind regards,
Lukas
The text was updated successfully, but these errors were encountered:
Hi Conor,
I was watching your latest talk about the algorithms/range adaptors that C++23 introduces. I'm excited to see you advertising this "sequential programming" style! I'm already a big fan of ranges, but mostly use the range-v3 library at the moment.
In the talk, you mention at around 1:13h that you could not come up with a more elegant way of simplifying the Sushi-for-Two problem using range-v3. You mostly criticize the issue that one cannot pipe into variadiac templates (like zip_with and concat). I fully agree that the Circle compiler has a neat solution for the general pipeline operator. However, I still believe that you can make the example a bit more elegant with "plain" range-v3 (see a full example in compiler explorer). I'm eager to hear what you think about my approach 🙂
pairwise_transform
adaptorYou have to introduce the temporary variables
indices
anddeltas
because you need to pipe them twice into thezip_with
range adaptor. However, you could simply make a custom range adaptor, i.e., thepairwise_transform
from C++23. Importantly, I make use of themake_pipeable
helper that not too many people utilize. While this does not solve the underlying problem that one cannot pipe into variadic templates, in your example you could get rid of the temporary variables.prepend
/append
adaptorsThese adaptors solve the "nonlinearity" issue with
concat
. I, personally, hated thatconcat
could not be piped into and it really breaks the flow of reading the code. Hence, I made myself the following two neat helpers that solved most of my problems. Of course these can be extended to appending/prepending ranges instead of single elements.Cheers and kind regards,
Lukas
The text was updated successfully, but these errors were encountered: