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.
@ 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
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
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"
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?
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.
@@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
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.
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...
@@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.
@@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).
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.
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.
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.
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.
@@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...
@@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.
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.
03:23 Off-by-one error. You meant index into the 11th element.
just zero index your english to match your code.
the traditionally "first" element is the zeroth element.
Changed update() to use std::span and that worked fine - figured that it would but just wanted to verify
Btw, span (like vector and array) is a contiguous_range and concat() of multiple contiguous ranges isn’t contiguous
@ 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
I'm surprised -Wno-error=unused-variable isn't a part of your usual command-line arguments for these videos.
I assume views::zip() also falls back to the lowest common denominator when it comes to deciding which iterator concept the view will model.
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
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"
cool feature
good
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?
They are both linear, at the end of the video he talks about the branch predictor which answers your question
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.
@@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
@@__Brandon__ Yeah, I'm mostly thinking in terms of array programming style (APL, J) where you emphasise Cartesian products, etc.
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.
From next video please increase font size, whenever possible
so the moral of the story is that std::views::concat is not magic but still useful
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...
@@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.
@@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).
@@Evan490BC But C compatibility made it a dominant language, unlike ML or Algol.
@@PaulTopping1 Indeed. You are right. But here we are...
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.
yea but thats boring! who cares about production! i want haskell in c++! lets add more features to an already bloated language!
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.
I guess I'm one of those 11 people
But C++26 comes out around 2066...
I'm still waiting for the bloody modules!
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
I am VERY skeptical to std::views after watching Nicolai Justtis cppcon talk. Seems totally broken and untrustworthy. What is your take on it?
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.
@@Evan490BC does std::views::as_const solve/help this in any way?
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.
@@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...
@@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.
one more bloating crap feature, with every standard c++ becomes worse and more bloated and worse and mwore bloated without a real reason