C++ Standard Views - Nico Josuttis - ACCU 2023
Vložit
- čas přidán 1. 06. 2023
- ACCU Membership: tinyurl.com/ydnfkcyn
Sponsored By think-cell: www.think-cell.com/accu
accu.org
C++ Standard Views: The Design, the Traps, and How to Use Them and How to Use Something Better - Nico Josuttis - ACCU 2023
Slides: accu.org/conf-previous/accu2023/
C++20 introduced views, lightweight collections that refer or own collections like containers or other ranges. The design had to deal with several tradeoffs. As a result, the standard views come with so many pitfalls and traps that they are really hard to use for experiences programmers and more or less unusable for ordinary programmers.
Why? How could that happen? How can we deal with what was standardized? Can we do better? Can we even implement or use other views.
This talk will answer all these questions and for sure cause heated discussions.
It is time to have them.
---
Nico Josuttis
Nicolai M. Josuttis is well-known in the C++ community for his authoritative books and talks. He is the author of "C++20 - The Complete Guide", "C++17 - The Complete Guide", "C++ Move Semantics - The Complete Guide", "The C++ Standard Library - A tutorial and Reference", and (as a co-author) "C++ Templates: The Complete Guide." He has been a member of the C++ Standards Committee for more than 20 years.
---
www.accuconference.org/
CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#accuconf #programming #cpp - Věda a technologie
![std::jthread - I Told You Concurrency Is Tricky - Nico Josuttis [ ACCU 2021 ]](http://i.ytimg.com/vi/ln5ERAVXEMY/mqdefault.jpg)
I love how talks with Nico turn to funny depression about "all is broken".
Excellent and very important talk. Thank you, Nico! We're with you.
Thank you so much for your comment.
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.
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.
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.
Strong voice. Cool
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.
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.
Can we use it with Eigen library ???
19:00, well, if you have std:list with million nodes... performance is not what bother you, for sure.
22:38 - "Do you think cheap is expensive?" - i sure hope nobody does.
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'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.