C++ Weekly - Ep 346 - C++23's bind_back
Vložit
- čas přidán 11. 09. 2024
- ☟☟ Awesome T-Shirts! Sponsors! Books! ☟☟
Upcoming Workshop: C++ Best Practices, NDC TechTown, Sept 9-10, 2024
► ndctechtown.co...
Upcoming Workshop: Applied constexpr: The Power of Compile-Time Resources, C++ Under The Sea, October 10, 2024
► cppunderthesea...
Episode notes: github.com/lef...
T-SHIRTS AVAILABLE!
► The best C++ T-Shirts anywhere! my-store-d16a2...
WANT MORE JASON?
► My Training Classes: emptycrate.com/...
► Follow me on twitter: / lefticus
SUPPORT THE CHANNEL
► Patreon: / lefticus
► Github Sponsors: github.com/spo...
► Paypal Donation: www.paypal.com...
GET INVOLVED
► Video Idea List: github.com/lef...
JASON'S BOOKS
► C++23 Best Practices
Leanpub Ebook: leanpub.com/cp...
► C++ Best Practices
Amazon Paperback: amzn.to/3wpAU3Z
Leanpub Ebook: leanpub.com/cp...
JASON'S PUZZLE BOOKS
► Object Lifetime Puzzlers Book 1
Amazon Paperback: amzn.to/3g6Ervj
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 2
Amazon Paperback: amzn.to/3whdUDU
Leanpub Ebook: leanpub.com/ob...
► Object Lifetime Puzzlers Book 3
Leanpub Ebook: leanpub.com/ob...
► Copy and Reference Puzzlers Book 1
Amazon Paperback: amzn.to/3g7ZVb9
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 2
Amazon Paperback: amzn.to/3X1LOIx
Leanpub Ebook: leanpub.com/co...
► Copy and Reference Puzzlers Book 3
Leanpub Ebook: leanpub.com/co...
► OpCode Puzzlers Book 1
Amazon Paperback: amzn.to/3KCNJg6
Leanpub Ebook: leanpub.com/op...
RECOMMENDED BOOKS
► Bjarne Stroustrup's A Tour of C++ (now with C++20/23!): amzn.to/3X4Wypr
AWESOME PROJECTS
► The C++ Starter Project - Gets you started with Best Practices Quickly - github.com/cpp...
► C++ Best Practices Forkable Coding Standards - github.com/cpp...
O'Reilly VIDEOS
► Inheritance and Polymorphism in C++ - www.oreilly.co...
► Learning C++ Best Practices - www.oreilly.co...
*Praying the god of c++ makes a coroutines video
Amen.
Checkout the cppcon channel, several new talks
There was a "Coroutines for Beginners" talk yesterday on cppcon, i feel i understand Coroutines somewhat now.
I have a topic request tracker to help me gauge viewer's interest in new topics. Add a thumbs up to the coroutine topic here if you'd like: github.com/lefticus/cpp_weekly/issues/
I remember std::bind being discouraged in favor of using lambdas instead, so it's interesting that std::bind_back was added
Lambdas are almost always better.
But if you habe to bind, use bind front or bind back, as they have less foot guns to worry about.
Besides footguns, they are much less complex. std::placeholders, while awesome, make bind a complex beast.
In functional programming languages, this capability is known as currying, from the esteemed Haskell Curry. Glad to see it added to the stdlib in C++23!
it's not, bind_front/back do partial function application (it's a tad different).
@@minirop Currying is a kind of partial function application. In fact, std::bind_front (with one argument given) _is_ currying.
I think we need a stand alone C++ weekly to go over the bind_back template/lambda code at the end of the session!
Definitely readable.
I realize, based on this topic, that using the bind functions seems like a good way to compose calls to functions like any_of, all_of or none_of, when you are working with ranges of simple values, or transformations to simple values. If you want to avoid using lambdas, because lambdas can be verbose.
such a simple feature yet so complicated to implement
That's the simple implementation. I'm sure the actual standard's compliant one would be much worse.
That template is a lot more readable than it would have been if implemented using, say, c++14, assuming it could even be implemented in c++14.
Templated lambdas are a godsend for stuff like this.
std::bind_back was added by the paper that adds user defined range adaptor stuff. Also I don't think your implementation is standard-compliant, as it doesn't forward on the value category of the binding object to the wrapped function (though this could be solved with deducing this!). Also I don't think returning a lambda would be acceptable in a standard library because if you try to pass around the binding object to functions and such, you could run into issues that you've gone over in one of your recent videos, with conflicting lambda types and such.
Can't we write a coroutine generator with a ranged view to lazily generate comments for your video?
"It's more readable [...], if you're used to reading code like this", what a glowing endorsement.
I'd be really interested in Linux version of this kind of video, or even open source focused
I need std::bind_middle
Why to use std::invoke ?
Because it correctly handles function, lambdas, member functions, and even variables (returns their value, as a getter function would), I think. Lots of cases you don't have to handle yourself.
While I'm a big fan of functional stuff like this, it really bothers me, that you can rarely make use of them and you have to use a lambda instead, which ends up slightly more verbose (forcing you to name each parameter and such).
E.g. it breaks when the function has overloads, has default parameters or is templated. And you can never know if a function that works now might change in one of these ways at some point in the future...
One of the things I really like about Rust btw. They ditched function overloads in favor of making stuff like this work seamlessly. Disallowing overloading might seem limiting at first, but thanks to generics/traits (which, unlike templates, do still work in cases like this) it's actually not a big deal imo.
Nice. Slight shame your example func took 2 params and you "bound_back" 2 params... which is the same as "bind_front" ?? 😁
When calling a member function like that, you also have to pass the `this` parameter as a normal parameter, so it is actually necessary ;)
It's not the same as bind_front because bind_front would try to bind the Point object parameter first.
@@Possseidon oh yeah... i am sick today... it's showing.
Personally, I dislike the syntactic mess that C++ has become. But at this point it's too late to be thoughtful with the syntax and make it more readable. Sadly, we have Rustaceans taking over and everything will eventually be Rust so we'll never get good syntax. Oh well, maybe I am right to make my own language since everything else sucks, except for plain ol' C and assembly. All that said, I enjoy these videos because you help me to keep up with the changing standard for C++ and I've incorporated a lot of ideas into my own language that I've gotten from others throughout the years.
Where I can know more about your language?
"Everything else sucks, except for plain ol' C and assembly."
2022 is here, wake up, it's not too late.
Oh and many programming tasks shouldn't (ever) use C and assembly, or don't need to go that low level. While many others should or could.
we need more '...'!
You should have skipped the invoke there - for the sake of readability.
I wanted it to be as complete as possible, while still as simple as possible. It's a tradeoff.
i do not think this is readable, for i am blind
isn't there a braille encoding for that?
Believe it or not, there are some programmers still say Python is easier to understand than C++. Let this video silence them forever.
Please do less ketamine, it's impossible to listen to you
Feel free to change the playback speed to suit your personal preference!