C++ Standard Views - Nico Josuttis

C++ Standard Views - Nico Josuttis - ACCU 2023

Рет қаралды 6,813

Жыл бұрын

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/
KZfaq Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
#accuconf #programming #cpp

Пікірлер: 23

@danielmilyutin9914 Жыл бұрын

I love how talks with Nico turn to funny depression about "all is broken".

@eugnsp Жыл бұрын

Excellent and very important talk. Thank you, Nico! We're with you.

@ACCUConf Жыл бұрын

Thank you so much for your comment.

@AlfredoCorrea Жыл бұрын

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.

@zz-oq2dt 22 күн бұрын

verry respect u ! Nico u are the best!

@videofountain 6 ай бұрын

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.

@XeroKimorimon Жыл бұрын

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

@XeroKimorimon Жыл бұрын

Well getting near the end of the presentation now and I shall take a look at the presenters fixed version of views.

@XiyueDeng Жыл бұрын

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.

@bryce.ferenczi 9 ай бұрын

@@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.

@thegeniusfool Жыл бұрын

Strong voice. Cool

@ABaumstumpf 2 ай бұрын

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.

@raymundhofmann7661 10 ай бұрын

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.

@benoitrousseau4137 11 ай бұрын

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.

@ilillillliiilillili 11 ай бұрын

19:00, well, if you have std:list with million nodes... performance is not what bother you, for sure.

@ABaumstumpf 2 ай бұрын

22:38 - "Do you think cheap is expensive?" - i sure hope nobody does.

@__hannibaalbarca__ 7 ай бұрын

Can we use it with Eigen library ???

@lukasz2345 Жыл бұрын

I'm going to learn rust. If such things can happen the process is broken :/ shame I rly like c++

@mgeding Жыл бұрын

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.

@chilippso 11 ай бұрын

GCC Runtime Library Exception (RLE) 3.1 applies in this case

@treyquattro Жыл бұрын

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.)

@eugnsp 10 ай бұрын

Some people proposed them, some supported, others didn't object. That's how it works.

@thewelder3538 23 күн бұрын

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.