Interesting. Now I'm wondering what a BF interpreter would look like. Imagine using #embed to import your program and run it at compile time. ++++++++++[>+++++++>+.
@@YarikTH It's useful when you need a simple state machine confined to a single method/function. There's no need for the cognitive overhead and context switching of creating a separate class somewhere else to refer to. Of course you could declare a state machine class inside the function, but that would still be more verbose.
@@turtlesoupage I'm already spending effort ignoring the generated classes that hold my lambdas, and this is really just "programming the compiler" to put more stuff I can't see into the generated class, which I find to be more of a cognitive burden than defining the class explicitly. That said, I think this would have been a good lightning talk, based on the recently released CPPCon '23 videos.
@@nyyakko That doesn’t seem to do much to stop the spammers. Tons of financial adviser spam in many videos I watch. They’re doing several posts per video, presumably in the hope one of them doesn’t get reported.
At this point, just declaring an inline struct seems to make it more obvious that you want to maintain state across calls, and the reader of you code doesn't have to remember nearly as much c++ trivia. E.g., just now I had to go google what "mutable" means in this context. Skill issue? Sure. But with c++, nearly everybody has skill issues.
Do you have a video about "language binding FFI" and what really happens under the hood? I know since almost everything is written in C++/C maybe it doesn't makes sense to talk about it but would still be great to understand that logic, for better understanding of computer logic.
I found that the ability for lambdas to capture variadic template parameters is quite convenient and ends up making you want to turn them into state machines rather than making a separate class that captures and uses the variadic stuff in a different way. Feels like a bit of an antipattern though maybe...
With all due respect I don't get the purpose of this video. As a occasional teacher myself I would never try to explain lambda as anything but a syntactic sugar over a class. And I don't think it should ever be explained in a different way. It acts like a class, compiles to a class, it is a class (and classes often do have states, which is quite obvious). Trying to push lambda as something other than a class, a separate concept only messes with people new to c++. Firstly in makes it harder to understand, because instead of just saying it is a concept that is known (or should be known to people who learn lambdas), and here is how lambda syntax translates to a class, it forces to learn a new concept from scratch and maybe overtime student will see that it acts in a same way. Secondly it adds confusion of what lambda actually is. What are the magic capture variables, or this magic mutable keyword? When to use lambda instead of function or class? Those questions may seem trivial to someone who has deep knowledge of c++, but are more then likely to be asked by the targeted audience of such video.
That's great for you as a teacher of C++. Is Jason teaching C++ or making interesting videos about C++ and all the interesting and weird things that it can do? "I thought this was an interesting aside for this channel, and as you know, I love to talk about lambdas." Sounds like the latter to me. I'm certainly not here to learn C++ from Jason, I here because I like seeing things I probably wouldn't want to do in a million years but it's cool to know they exist and if I learn useful things along the way then I see that as a bonus.
Thinking about lambdas as "magic" classes is also misleading, IMO, even if it's how they are implemented. Rather than teach that they are syntactic sugar for classes, you should be teaching about closures. Classes are a special case of closures, though that idea may be a bit advanced in an entry-level C++ class. It's more of a theory and design concept. But closures are an important concept that has implications in many languages, especially with all the adoption of functional syntax in modern language. Some languages that support closures don't have the concept of classes at all. The concept of closures is portable to every language that uses lambdas, which is most of them now. That said, this channel is not only about entry-level C++ concepts. Quite the contrary, in fact. While he has some more entry-level videos, and a new series all about fundamentals, he tends to get down in the weeds to help advanced users understand C++ more deeply.
C++ coroutines are implemented essentially like this state machine lambda. Each "co_yield" becomes a state. So they're just a helper to write this kind of state machine, but using straightforward, normal looking code. It's usually easier to see what a generator is doing, than to trace through a bunch of cases in a switch.
Usually the response I've heard is "the compiler is able to better optimize coroutines than stateful lambdas" but I have 0 idea how or in what way and coroutines in C++ are (still) a pain to actually get working so for now I'm always just using stateful lambdas when I need stuff like this.
Minor nitpick: under "case: Startup", "state = Numbers" should be outside the conditional. As it stands, "3-3" and "33-" parse as -33.
Oops
6:10 the modification didn't compile in time for the video section, made me chuckle 😂 Ah C++, I love you as much as I hate you..
Haskell devs are giving us the thousand yard stare right now
Not lazy enough 😂
Interesting. Now I'm wondering what a BF interpreter would look like. Imagine using #embed to import your program and run it at compile time. ++++++++++[>+++++++>+.
hmmm that CLion ad
It is literally a parser class without any flexibility that class gives you
It's an example to illustrate the idea.
@@turtlesoupage and I don't see any advantage this idea has over writing a classic C++ class
Yeah, I definitely missed a hint if/when this makes sense or if it is just toying around
@@YarikTH It's useful when you need a simple state machine confined to a single method/function. There's no need for the cognitive overhead and context switching of creating a separate class somewhere else to refer to. Of course you could declare a state machine class inside the function, but that would still be more verbose.
@@turtlesoupage I'm already spending effort ignoring the generated classes that hold my lambdas, and this is really just "programming the compiler" to put more stuff I can't see into the generated class, which I find to be more of a cognitive burden than defining the class explicitly.
That said, I think this would have been a good lightning talk, based on the recently released CPPCon '23 videos.
You finally convinced me to buy the lambda llama shirt!
Two porn bots in the comments.
I always report those, they're so annoying.
@@nyyakko That doesn’t seem to do much to stop the spammers. Tons of financial adviser spam in many videos I watch. They’re doing several posts per video, presumably in the hope one of them doesn’t get reported.
Sorry - I do make an effort to remove those. I don't check for them daily though, so any efforts by viewers to report them is appreciated!
@@cppweekly It wasn't intended as a criticism of you, in case that's how it came across.
i was just speculating in my head the other day about implementing coroutines through lambdas just like this.
github.com/lefticus/tools/blob/main/include/lefticus/tools/lambda_coroutines.hpp
At this point, just declaring an inline struct seems to make it more obvious that you want to maintain state across calls, and the reader of you code doesn't have to remember nearly as much c++ trivia. E.g., just now I had to go google what "mutable" means in this context. Skill issue? Sure. But with c++, nearly everybody has skill issues.
Do you have a video about "language binding FFI" and what really happens under the hood? I know since almost everything is written in C++/C maybe it doesn't makes sense to talk about it but would still be great to understand that logic, for better understanding of computer logic.
I found that the ability for lambdas to capture variadic template parameters is quite convenient and ends up making you want to turn them into state machines rather than making a separate class that captures and uses the variadic stuff in a different way. Feels like a bit of an antipattern though maybe...
Reminds me a bit of generators from Python (sorta).
With all due respect I don't get the purpose of this video. As a occasional teacher myself I would never try to explain lambda as anything but a syntactic sugar over a class. And I don't think it should ever be explained in a different way. It acts like a class, compiles to a class, it is a class (and classes often do have states, which is quite obvious). Trying to push lambda as something other than a class, a separate concept only messes with people new to c++. Firstly in makes it harder to understand, because instead of just saying it is a concept that is known (or should be known to people who learn lambdas), and here is how lambda syntax translates to a class, it forces to learn a new concept from scratch and maybe overtime student will see that it acts in a same way. Secondly it adds confusion of what lambda actually is. What are the magic capture variables, or this magic mutable keyword? When to use lambda instead of function or class? Those questions may seem trivial to someone who has deep knowledge of c++, but are more then likely to be asked by the targeted audience of such video.
That's great for you as a teacher of C++. Is Jason teaching C++ or making interesting videos about C++ and all the interesting and weird things that it can do?
"I thought this was an interesting aside for this channel, and as you know, I love to talk about lambdas." Sounds like the latter to me.
I'm certainly not here to learn C++ from Jason, I here because I like seeing things I probably wouldn't want to do in a million years but it's cool to know they exist and if I learn useful things along the way then I see that as a bonus.
Thinking about lambdas as "magic" classes is also misleading, IMO, even if it's how they are implemented. Rather than teach that they are syntactic sugar for classes, you should be teaching about closures. Classes are a special case of closures, though that idea may be a bit advanced in an entry-level C++ class. It's more of a theory and design concept. But closures are an important concept that has implications in many languages, especially with all the adoption of functional syntax in modern language. Some languages that support closures don't have the concept of classes at all. The concept of closures is portable to every language that uses lambdas, which is most of them now.
That said, this channel is not only about entry-level C++ concepts. Quite the contrary, in fact. While he has some more entry-level videos, and a new series all about fundamentals, he tends to get down in the weeds to help advanced users understand C++ more deeply.
Seems like the Discount Code isn’t working for renewals.
I'll look into that
I reached out to JetBrains and it seems the code is only good for yearly renewals.
How is making an actual generator with co_yield better than using a stateful lambda?
Was indeed gonna compare as stateful lambda and coroutines.
C++ coroutines are implemented essentially like this state machine lambda. Each "co_yield" becomes a state. So they're just a helper to write this kind of state machine, but using straightforward, normal looking code. It's usually easier to see what a generator is doing, than to trace through a bunch of cases in a switch.
Usually the response I've heard is "the compiler is able to better optimize coroutines than stateful lambdas" but I have 0 idea how or in what way and coroutines in C++ are (still) a pain to actually get working so for now I'm always just using stateful lambdas when I need stuff like this.
I certainly never said it was better to use co_yield!
@@cppweekly you never did, i just assumed :))
Any chance you will visit Sweden as well in near future?
I'm happy to go wherever I'm hired to go!
@@cppweekly That's the mindset!
amazing