C++ Weekly - Ep 461 - C++26's std::views::concat

☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Upcoming Workshops:
► C++ Best Practices Workshop, ACCU, Bristol UK, Mar 31, 2025: accuconference...
Episode details: github.com/lef...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2...
WANT MORE JASON?
► My Training Classes: emptycrate.com/...
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/spo...
► Paypal Donation: www.paypal.com...
GET INVOLVED
► Video Idea List: github.com/lef...
JASON'S BOOKS
► C++23 Best Practices
Amazon Paperback: amzn.to/47MEAhj
Leanpub Ebook: leanpub.com/cp...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cp...
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/ob...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/co...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/op...
RECOMMENDED BOOKS
► Bjarne Stroustrup's A Tour of C++ (now with C++20/23!): amzn.to/3X4Wypr
AWESOME PROJECTS
► The C++ Starter Project - Gets you started with Best Practices Quickly - github.com/cpp...
► C++ Best Practices Forkable Coding Standards - github.com/cpp...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.co...
► Learning C++ Best Practices - www.oreilly.co...

[@KX36]

Have you ever considered turning off automatic compile on change in Compiler Explorer (Ctrl+Shift+Enter) so that you have to hit Ctrl+Enter to compile? It would save a lot of waiting for the half typed line to fail to compile before it tries again with the fully typed line.

[@cppweekly]

Absolutely not. This is what I love about CE. I don't have to wait, and often don't. And if you're still typing it doesn't send the code out to compile.

[@huixie2485]

Thanks for promoting views::concat. One of the reasons we proposed this view is to make it easy to concat the ranges "correctly". Taking the example in this video to just print some numbers with ` ` as the separator, without concat, it is actually not very easy to make it bug-free. For example, what if one of the ranges is empty, do you write an extra ' ` then it should have been?

[@TheSulross]

Changed update() to use std::span and that worked fine - figured that it would but just wanted to verify

[@Roibarkan]

Btw, span (like vector and array) is a contiguous_range and concat() of multiple contiguous ranges isn’t contiguous

[@TheSulross]

@ span, like array and vector supports [] and so looks like from concat perspective, span had all the necessary ingredients (start of the first element, number of elements, support of []) that it relies on to do its thing

[@robertshepherdcpp]

cool feature

[@sledgex9]

03:23 Off-by-one error. You meant index into the 11th element.

[@KX36]

just zero index your english to match your code. the traditionally "first" element is the zeroth element.

[@12nites]

I assume views::zip() also falls back to the lowest common denominator when it comes to deciding which iterator concept the view will model.

[@Roibarkan]

Yep. There’s a proposal to add a range concept for ‘finite_range’ (or infinite_range) where zip_view will be infinite if all its members are infinite (and sized if all its finite members are sized), vs. concat which will be infinite if one member is infinite. In that sense, concat is more similar to cartesian_product than to zip

[@Roibarkan]

To be particular - I think zip_view is a borrowed_range if all its members are whereas neither concat_view nor cartesian_product_view are "borrowed_range"

[@Minty_Meeo]

I'm surprised -Wno-error=unused-variable isn't a part of your usual command-line arguments for these videos.

[@vankhoan231]

good

[@OlliS71]

But this is for sure somewhat slower than two distinct loops.

[@cppweekly]

Probably not. Did you measure it? Pretty sure the code we looked at says it wouldn't be slower.

[@ChrisM541]

Question: With more and more features added in each iteration, C++ is in danger of devolving/abstracting into a high level language? Many of the functions added recently can most certainly NOT be described as low level. Where will this end?

[@mina86]

C++ has always been high level language. Virtual inheritance is very high-level concept for example.

[@ChrisM541]

@@mina86 What I mean is that we're getting further and further away from influencing the resulting machine code. This is significantly negatively impacting both executable size and execution speed. As the abstraction continues, you end up with 'general purpose' high level constructs i.e. 'naturally' unoptimized. Yes, you can manually adjust the assembly code, but doing that at an expert level is a skill virtually devoid today. Compilers are bad enough today - the same source compiled using different compilers will yield very, very different machine code. This should be a growing concern.

[@mina86]

@ChrisM541 , no, that should not be a growing concern. Why would it? C++ has never been close to machine code. It never promised anything about generated code. Furthermore, higher level abstraction which encode programmer's intent and existing constraint let compilers make smarter decisions.

[@anon_y_mousse]

If I were designing the library I wouldn't differentiate between contiguous and non-contiguous containers, I would just add a warning to alert the programmer to the potential cost. That said, why the fart is anyone still using std::list or generic linked lists as a go-to container of any kind? Haven't we all learned the lesson by now that arrays are superior to linked structures, even trees.

[@narc212]

If I have 2 or 3 vectors with objects of the same type and only in one place I have to iterate over all of them, is it better to use std::views::concat than creating 2 or 3 for loops? will std::views::concat help me find an element faster?

[@__Brandon__]

They are both linear, at the end of the video he talks about the branch predictor which answers your question

[@Evan490BC]

I am not obsessing over efficiency, personally. I think all these new features lead to cleaner and more functional and, by implication, more composable code, so I tend to prefer them.

[@__Brandon__]

@@Evan490BC the enumerate is pretty cool. But they are also extremely efficient if you actually need to concat 3 ranges. If you just need to loop 3 ranges it's not really the right tool. But random access over 3 vectors joined, or doing a quick find on multiple span... This is the right tool

[@Evan490BC]

@@__Brandon__ Yeah, I'm mostly thinking in terms of array programming style (APL, J) where you emphasise Cartesian products, etc.

[@cycomkid]

From next video please increase font size, whenever possible

[@PaulTopping1]

so the moral of the story is that std::views::concat is not magic but still useful

[@Evan490BC]

This is C++'s life-story; be almost good but in the end screw everything up... Take non-destructive, non "memcpy" move semantics in C++, as compared to those of Rust, for example...

[@PaulTopping1]

@@Evan490BC I think it's unfair to compare C++ to Rust since the former has delivered 50 years of backwards compatibility. It has made some wrong moves but I doubt if we'd all agree on which ones.

[@Evan490BC]

@@PaulTopping1 Yes, this is true. The mistakes were made during the early years of its development, when it adopted C's broken type system. There were better type systems even back then (ML's or Algol 60's, for example).

[@PaulTopping1]

@@Evan490BC But C compatibility made it a dominant language, unlike ML or Algol.

[@Evan490BC]

@@PaulTopping1 Indeed. You are right. But here we are...

[@brockdaniel8845]

But C++26 comes out around 2066...

[@Evan490BC]

I'm still waiting for the bloody modules!

[@kuhluhOG]

when it comes to support in new compiler version, no when it comes to the compiler you are allowed to use at your job, maybe, depends on workplace

[@lbgstzockt8493]

Maybe instead of adding random features 11 people will ever use the C++ standards body could make error messages less than 2000 lines long and actually tell me what went wrong. Or finally force everybody to use one (1) package manager so it sucks less to use external libraries.

[@shipweck6253]

yea but thats boring! who cares about production! i want haskell in c++! lets add more features to an already bloated language!

[@oleksiistri8429]

so true, that is why i move away from c++ more and more, i do not really care that much about performance anymore, today i want to enjoy programming and to see my code cleaner and being understandable when i get back to it after 1 year, with c++ 2011 i enjoyed it, but all this 2020-2026 "features" make me sick even looking at it.

[@eggmeister6641]

I guess I'm one of those 11 people

[@the_mathias]

I am VERY skeptical to std::views after watching Nicolai Justtis cppcon talk. Seems totally broken and untrustworthy. What is your take on it?

[@Evan490BC]

It's controversial. The issue comes from the fact that `std::view`s do not propagate const, as pointers (and references) don't, and some of them are not `const`-iterable. I think the latter can be resolved, from the programmer's point of view, by knowing which std::views are `const`-iterable and which are not, and using them accordingly.

[@shipweck6253]

@@Evan490BC does std::views::as_const solve/help this in any way?

[@robertfrysch7985]

As long as a view is not owning the data, it's a consistent design decision to not propergate `const` (likewise for span or string_view). I think the major mistake was that some views cache the begin iterator, so that the `begin()` method is not a `const` member function. This is really unfortunate and leads to a complex behavior (which is dependent on the underlying container) that's not worth it, as only very rare use cases benefit from this caching mechanism.

[@Evan490BC]

@@robertfrysch7985 Yes, I agree. The question is how do we go forward from here. I know there are different opinions within the C++ committee regarding those design decisions. But, as you say, the current design leads to accidental complexity semantically. I'm just not sure if it's "fixable" now...

[@robertfrysch7985]

@@Evan490BC I guess, technically, it could be fixed without breaking too much. However, I think in > 90% of the cases, you would use `views` with contiguous containers anyway, where no caching happens. So maybe, as long as it's not fixed, we could consider `views` as a library for random access containers.

[@vankhoan231]

sad

[@oleksiistri8429]

one more bloating crap feature, with every standard c++ becomes worse and more bloated and worse and mwore bloated without a real reason

[@WilhelmDrake]

I couldn't disagree more.

[@vankhoan231]

good