Of course, Nico is mostly correct. There is no place for caching/ref-counting and too-smart stuff in a low-level library. What needs to be included in this discussion, both from the standard and from Nico, is that filter views can have lower categories than bidirectional. A mutating filter view is something very specific (I don't have a name for it), something in between forward-iterable and input-iterable ranges. We used to be rational about this stuff; we talked in terms of iterator *categories* and iterator *invalidation* , without a conceptual framing any design can be accepted as valid. The problem is thinking that these details are not important for ranges; mathematically, ranges also have categories and even more complex ones than the ones we used for iterators (which were incomplete even at the time); they can also be self- or remotely invalidated which is the common trait in the examples. Having said this, diminishing the usefulness of `const&` in ranges code is not just bad for teaching; it is catastrophic for generic programming as well, and in that, I am 100% aligned with what Belleviews is trying to fix.
I appreciate the rare honesty of the presentation. Even the presentation of the fact that Mr. N. Josuttis objected to certain designs and was ignored unanimously.
ranges/view were one of the main things why i tried making our codebase ready for C++20. Even just the small things like splitting strings. And then we saw that while you could split strings there was no way of concatenating them back together in a similar style - ok, so we have to create our own compatible functionalities for that (the committee "forgot" about that and it was later added to C++23). Still not too bad - so lets test it... wait, why is everything broken? oooohhhh views are caching... and the code would need extensive reworking due to changes to enum, bool, volatile etc.... Yup, and back to C++17.
54:57 Instead of forcing the begin computation to be cached under certain conditions based on the underlying container and view used, couldn't there be a std::views::cache_begin or something like that which would actually cache the first call to begin? I feel like a decent amount of surprises could be avoided, in return of having to be conscious of when caching would speed up performance, instead of the library deciding it for us. For example on that slide a hypothetical coll | std::views::filter(isEven); would now be fine being used multiple times because begin will be computed every single time we iterate, and shouldn't be UB anymore, but a coll | std::views::filter(isEven) | std::views::cache_begin; would have begin cached on first call and would get UB behaviour when trying modify the view so that it's elements break the predicate
I guess if they name it cache_begin they think no one will use it because everyone knows C++ only knows about the begin/end pair and cbegin/cend pair, so it's important to take those popular names.
@@XiyueDeng cache_begin would be just another range adapter that saves the begin reference, it would still have begin/end etc. I think this is a good idea, the programmer is more explicit when they want to save a linear begin() when this is needed.
The caching seems to violate both the principles of least surprises, and the principle of not paying for what you don't use. It's trivial to cache a begin() iterator yourself and you don't need to if you only iterate once through the collection, so I don't think it should be the role of the library to cache for you. I also don't think it's particularly useful to cache filter because you still have to test all the other elements of the list. I used the view API expecting it to work like a simple "pipeline" design with no state, just like Ruby's Enumerable module, or C#'s LINQ library. Turns out I had a surprise with iota_view, looks like the counter is on the view rather than the iterator so it could not be enumerated as a const range. I would have to hear the other side's arguments, but the view library does seem to be built on shaky grounds. Hopefully the committee does not let the view library rot with its warts, but looking at the state of std::regex, I'm not particularly hopeful about that... Thank you for making the talk, that was very interesting to watch.
This reminds me of the lack of compiler diagnostics and IDEs having useful static analysis tools for lifetime checking for references and concurrent programming. We have it standardized like it is now, but if we could chose the tools to reject or flag the UB constructs, we only have a questionable standard, but not necessary questionable programs created.
Nicolai is always worth listening to. But if what he describes about views is correct, and I don't doubt that it is, then I have to wonder why these behaviors were allowed to be formalized. Also, who asked for ranges and views functionality? Was it just to compete with LINQ in C# and perhaps similar features in other languages? It's not something that I've ever used, nor ever wanted. It is any wonder that C++ gets a reputation for flakiness, and why companies and governments are starting to mandate against its use?! (OK, not entirely the issue at hand, but not far removed.)
Great talk about the traps that C++ programmers can fall into with std::views. However the suggested belleviews library has GPL licensing which is too restrictive for many people.
I like the whole idea of views, but I'm concerned about the performance of this stuff. I'm pretty sure, although I don't have any evidence for this, that it would be faster to do what you're getting with a view yourself. Maybe it would be more readable as a view, I don't know, it would certainly be more concise, but that doesn't always equate to readability. Having views might be more confusing to junior programmers than something you've done yourself. This sort of thing with views and stuff has existed in C# for ages with Linq and it preformed pretty badly there. So as a concept, views seem okay, but outside the odd case or two, I've got no real need for them. In my opinion, a lot of these things they're cramming into the standard are like things to include just for the sake of inclusion, not for any real worldly benefit. Sure, they're nice to have but are they going to change the way that most C++ developers write code, probably not. Well, not unless you're one of those annoying bleeding edge coders who likes to shoehorn a spaceship operator in their code whenever they can.
Actually no. I've started using views in production, and you actually eliminate both bad performing code patterns and complex-for-performance (best place for hidden bugs) code patterns. Sometimes you get it wrong (as any code can be), but at least it's more readable and you can reason about it.
![C++17 - The Best Features - Nicolai Josuttis [ACCU 2018]](http://i.ytimg.com/vi/e2ZQyYr0Oi0/mqdefault.jpg)
Another excellent talk by Niko. His talks are as valuable as his books.
Excellent and very important talk. Thank you, Nico! We're with you.
Thank you so much for your comment.
I love how talks with Nico turn to funny depression about "all is broken".
Of course, Nico is mostly correct. There is no place for caching/ref-counting and too-smart stuff in a low-level library. What needs to be included in this discussion, both from the standard and from Nico, is that filter views can have lower categories than bidirectional. A mutating filter view is something very specific (I don't have a name for it), something in between forward-iterable and input-iterable ranges. We used to be rational about this stuff; we talked in terms of iterator *categories* and iterator *invalidation* , without a conceptual framing any design can be accepted as valid. The problem is thinking that these details are not important for ranges; mathematically, ranges also have categories and even more complex ones than the ones we used for iterators (which were incomplete even at the time); they can also be self- or remotely invalidated which is the common trait in the examples. Having said this, diminishing the usefulness of `const&` in ranges code is not just bad for teaching; it is catastrophic for generic programming as well, and in that, I am 100% aligned with what Belleviews is trying to fix.
I appreciate the rare honesty of the presentation. Even the presentation of the fact that Mr. N. Josuttis objected to certain designs and was ignored unanimously.
verry respect u ! Nico u are the best!
ranges/view were one of the main things why i tried making our codebase ready for C++20. Even just the small things like splitting strings. And then we saw that while you could split strings there was no way of concatenating them back together in a similar style - ok, so we have to create our own compatible functionalities for that (the committee "forgot" about that and it was later added to C++23).
Still not too bad - so lets test it... wait, why is everything broken? oooohhhh views are caching... and the code would need extensive reworking due to changes to enum, bool, volatile etc.... Yup, and back to C++17.
54:57 Instead of forcing the begin computation to be cached under certain conditions based on the underlying container and view used, couldn't there be a std::views::cache_begin or something like that which would actually cache the first call to begin? I feel like a decent amount of surprises could be avoided, in return of having to be conscious of when caching would speed up performance, instead of the library deciding it for us.
For example on that slide a hypothetical coll | std::views::filter(isEven); would now be fine being used multiple times because begin will be computed every single time we iterate, and shouldn't be UB anymore, but a coll | std::views::filter(isEven) | std::views::cache_begin; would have begin cached on first call and would get UB behaviour when trying modify the view so that it's elements break the predicate
Well getting near the end of the presentation now and I shall take a look at the presenters fixed version of views.
I guess if they name it cache_begin they think no one will use it because everyone knows C++ only knows about the begin/end pair and cbegin/cend pair, so it's important to take those popular names.
@@XiyueDeng cache_begin would be just another range adapter that saves the begin reference, it would still have begin/end etc. I think this is a good idea, the programmer is more explicit when they want to save a linear begin() when this is needed.
The caching seems to violate both the principles of least surprises, and the principle of not paying for what you don't use. It's trivial to cache a begin() iterator yourself and you don't need to if you only iterate once through the collection, so I don't think it should be the role of the library to cache for you. I also don't think it's particularly useful to cache filter because you still have to test all the other elements of the list.
I used the view API expecting it to work like a simple "pipeline" design with no state, just like Ruby's Enumerable module, or C#'s LINQ library. Turns out I had a surprise with iota_view, looks like the counter is on the view rather than the iterator so it could not be enumerated as a const range.
I would have to hear the other side's arguments, but the view library does seem to be built on shaky grounds. Hopefully the committee does not let the view library rot with its warts, but looking at the state of std::regex, I'm not particularly hopeful about that...
Thank you for making the talk, that was very interesting to watch.
This reminds me of the lack of compiler diagnostics and IDEs having useful static analysis tools for lifetime checking for references and concurrent programming. We have it standardized like it is now, but if we could chose the tools to reject or flag the UB constructs, we only have a questionable standard, but not necessary questionable programs created.
Strong voice. Cool
19:00, well, if you have std:list with million nodes... performance is not what bother you, for sure.
Can we use it with Eigen library ???
I'm going to learn rust. If such things can happen the process is broken :/ shame I rly like c++
Nicolai is always worth listening to. But if what he describes about views is correct, and I don't doubt that it is, then I have to wonder why these behaviors were allowed to be formalized. Also, who asked for ranges and views functionality? Was it just to compete with LINQ in C# and perhaps similar features in other languages? It's not something that I've ever used, nor ever wanted.
It is any wonder that C++ gets a reputation for flakiness, and why companies and governments are starting to mandate against its use?! (OK, not entirely the issue at hand, but not far removed.)
Some people proposed them, some supported, others didn't object. That's how it works.
Great talk about the traps that C++ programmers can fall into with std::views. However the suggested belleviews library has GPL licensing which is too restrictive for many people.
GCC Runtime Library Exception (RLE) 3.1 applies in this case
I like the whole idea of views, but I'm concerned about the performance of this stuff. I'm pretty sure, although I don't have any evidence for this, that it would be faster to do what you're getting with a view yourself. Maybe it would be more readable as a view, I don't know, it would certainly be more concise, but that doesn't always equate to readability. Having views might be more confusing to junior programmers than something you've done yourself.
This sort of thing with views and stuff has existed in C# for ages with Linq and it preformed pretty badly there. So as a concept, views seem okay, but outside the odd case or two, I've got no real need for them.
In my opinion, a lot of these things they're cramming into the standard are like things to include just for the sake of inclusion, not for any real worldly benefit. Sure, they're nice to have but are they going to change the way that most C++ developers write code, probably not. Well, not unless you're one of those annoying bleeding edge coders who likes to shoehorn a spaceship operator in their code whenever they can.
Actually no. I've started using views in production, and you actually eliminate both bad performing code patterns and complex-for-performance (best place for hidden bugs) code patterns. Sometimes you get it wrong (as any code can be), but at least it's more readable and you can reason about it.
22:38 - "Do you think cheap is expensive?" - i sure hope nobody does.