Why doesn't compilation just fail right away when passing an r-value reference to a range...? Instead it produces a noop object that produces a very confusing message when you try to use it . I wouldn't call that "really cool" :(
But is that dangling iterator really a problem? You wouldn't want to dereference it without checking against container.end() anyways and at that point you would notice your mishap. For example if the container given to min_element is empty, then even if it wasn't dangling you would have a problem trying to dereference it.
I answered a question about this at the end... basically it would stop you doing useful things, like ranges::copy(get_vector(), output_iter); where you generally don't care that the returned iterator is dangling, because you don't use it. I actually think that the error message is helpful once you know what ranges::dangling is, certainly moreso than the "no matching overload" you'd get otherwise.
This is one of the best channels I found for C++, and I'll be forever on my recommendation list for anyone who practices C++. Can anyone suggest a similar channel for java?
About trim_back: I'm new to ranges/views. My understanding is you cascade views using | op. They are not executed at definition/declaration. They become active when used in an algorithm where iterator(s) browse a collection (here, a string of char). Am I right until here? If so, trim_back is composed of 3 operations. My question is: Will those 3 operations be executed once per string (so the iterator runs on the final resulting view) or once per iterator step (i.e for each single char in the string)?
Great presentation. In the end, when using inline constexpr variables for trim_front, trim_back, and trim_str, why not defining trim_str as an inline constexpr as well? Just because it could be confusing to whoever uses trim_str?
Thanks :) I just kept trim_str as a function to show how to use "ranges-style" pipelines in ordinary functions which take strings and vectors etc. You could replace it with an inline constexpr function object if you wanted to.
23:25 I can already feel that a lot of programmers are just going to ignore the "constant time" constraint and enable that vector can be treated like a view.
The iterator type is something very like std::variant, where I and S are the original iter and sentinel types. I've never measured the overhead, but I'd be curious to know what it is (if anything).
I'm not faulting the presenter but I can't help conclude that C++ is growing very complicated. Views and borrowed ranges, for example, are similar but different and one can be converted into another. Isn't that the very definition of confusion? I realize that each of these language features solves a problem but the added mass to the language may well sink it. We hear it said that there's a powerful new language embodied in C++20 but is it really that clean? How would it compare to a language built from scratch around the same goals? In other words, how close is C++20's baggage to zero? It would be great for someone to create a C++ variant that embodies all the good ideas in C++20 without all the deprecated stuff and (important) all the compromises forced on the language by backward compatibility.
What's that all about with `ranges::dangling`? Why?! It must be totally possible to return an "iterator" (a thing that behaves like an iterator) which also contains a moved copy of the input range in its internal state -- this way it would all work properly for rvalues. Why such a weird decision from the committee instead?
But having such an iterator that points to 1 isolated element is weird, what happens when you increment it? It is effectively as if you've created another range with length 1 and returned it. And of course that element has to live somewhere and the iterator is just pointing to it, then the lifetime of that element would have to be extended and it would require a dynamic allocation.
Instead of piling even more onto , splitting this mega header would be nice.
We will all be doing import std; in C++23, so what is in which header will not really matter.
what a high quality voice presentation!
For anyone looking for Tristan's introductory talk on ranges, which precedes this one, here is the link: th-cam.com/video/SYLgG7Q5Zws/w-d-xo.html
Thanks man!
Thank you so much!
You can improve trim_back on 58:36
inline constexpr auto trim_back = views::reverse | trim_front | views::reverse;
Of course, this way of implementing trim_back means that it only works on reversible ranges, and not on forward ranges.
Indeed, well spotted! :)
Why doesn't compilation just fail right away when passing an r-value reference to a range...? Instead it produces a noop object that produces a very confusing message when you try to use it . I wouldn't call that "really cool" :(
But is that dangling iterator really a problem? You wouldn't want to dereference it without checking against container.end() anyways and at that point you would notice your mishap. For example if the container given to min_element is empty, then even if it wasn't dangling you would have a problem trying to dereference it.
I answered a question about this at the end... basically it would stop you doing useful things, like ranges::copy(get_vector(), output_iter); where you generally don't care that the returned iterator is dangling, because you don't use it. I actually think that the error message is helpful once you know what ranges::dangling is, certainly moreso than the "no matching overload" you'd get otherwise.
This is one of the best channels I found for C++, and I'll be forever on my recommendation list for anyone who practices C++.
Can anyone suggest a similar channel for java?
4 months and no answers on this question. Java seems to lack the same vibrancy as C++ in its developer community.
@@natedoggstyle Or maybe Java developers aren't watching cppcon videos? I'm not watching Java videos and wouldn't, even if you paid me.
The example at 12:40 does not compile because string_view{}..}.begin() returns an iterator to const
Oops! Well spotted
About trim_back: I'm new to ranges/views. My understanding is you cascade views using | op. They are not executed at definition/declaration. They become active when used in an algorithm where iterator(s) browse a collection (here, a string of char). Am I right until here?
If so, trim_back is composed of 3 operations. My question is: Will those 3 operations be executed once per string (so the iterator runs on the final resulting view) or once per iterator step (i.e for each single char in the string)?
Great video!
Thanks for the visit
Great presentation. In the end, when using inline constexpr variables for trim_front, trim_back, and trim_str, why not defining trim_str as an inline constexpr as well? Just because it could be confusing to whoever uses trim_str?
Thanks :) I just kept trim_str as a function to show how to use "ranges-style" pipelines in ordinary functions which take strings and vectors etc. You could replace it with an inline constexpr function object if you wanted to.
Can trim_str be constexpr?
23:25 I can already feel that a lot of programmers are just going to ignore the "constant time" constraint and enable that vector can be treated like a view.
I wonder if there is a concept for valid_iter_type or something? To screen out template instantiation with a ranges::dangling ?
What is the overhead of views::common? Is there a known overhead or does it end up getting optimized out?
The iterator type is something very like std::variant, where I and S are the original iter and sentinel types. I've never measured the overhead, but I'd be curious to know what it is (if anything).
I was expecting to see `accumulate` at the end of a pipeline.
38:58 - don't you need to pass std::plus because "defaulted" machinery won't work for comparison function as expected?
No, it can be defaulted as written, see gcc.godbolt .org/z/zbGE8a for example
At 57:29, I'm fairly sure the inline isn't necessary, as constexpr implies inline.
It is necessary. constexpr doesn't imply inline for variables.
For preciseness, constexpr doesn't imply inline for namespace scope variables, but for static member variable it implies inline.
Link to previous talk: th-cam.com/video/SYLgG7Q5Zws/w-d-xo.html
I'm not faulting the presenter but I can't help conclude that C++ is growing very complicated. Views and borrowed ranges, for example, are similar but different and one can be converted into another. Isn't that the very definition of confusion? I realize that each of these language features solves a problem but the added mass to the language may well sink it. We hear it said that there's a powerful new language embodied in C++20 but is it really that clean? How would it compare to a language built from scratch around the same goals? In other words, how close is C++20's baggage to zero? It would be great for someone to create a C++ variant that embodies all the good ideas in C++20 without all the deprecated stuff and (important) all the compromises forced on the language by backward compatibility.
At that point you can use a totally different language. Why call it C++ if it doesn't compile vast majority of C++?
Use #Rust or #Dlang
have you heard of cppfront/cpp2 from Herb Sutter? it's a project exactly as you described
The CppCon 2019 talk: th-cam.com/video/SYLgG7Q5Zws/w-d-xo.html
What's that all about with `ranges::dangling`? Why?!
It must be totally possible to return an "iterator" (a thing that behaves like an iterator) which also contains a moved copy of the input range in its internal state -- this way it would all work properly for rvalues. Why such a weird decision from the committee instead?
But having such an iterator that points to 1 isolated element is weird, what happens when you increment it? It is effectively as if you've created another range with length 1 and returned it. And of course that element has to live somewhere and the iterator is just pointing to it, then the lifetime of that element would have to be extended and it would require a dynamic allocation.
@@hacker2ish Wouldn't it still just contain the range, just that it would increment which element within it that the iterating is pointing to?
24:47 std::accumulate is more then this.
In what way?