Value Oriented Programming Part 1: You Say You Want to Write a Function - Tony Van Eerd CppNow 2023
Vložit
- čas přidán 6. 09. 2023
- www.cppnow.org
/ cppnow
---
Value Oriented Programming. Part 1: You Say You Want to Write a Function - Tony Van Eerd - CppNow 2023
Slides: github.com/boostcon
---
At the first BoostCon (2007), Sean Parent gave the Best. Keynote. Ever. Introducing many to Value Semantics. Some (who are probably reading this) said it fundamentally changed how they code. During the questions at the end, Dave Abrahams asked "how do we teach this".
Here is the start of my answer:
Aaahhh!
You say you want to write a function
Well, you know
We all want to change the code
You tell me that it's evolution
Well, you know
We all want to change the code
But when you talk about member functions
Don't you know that you can count me out?
Don't you know it's gonna be
All right
All right
All right
You say you got a real solution
Well, you know
We'd all love to see the plan
You ask me for a contribution
Well, you know
We all doing what we can
But if you want money for params with all that state
All I can tell you is, developer, you have to wait
Don't you know it's gonna be
All right
All right
All right
You say you'll change the param direction
Well, you know
We all want to change your head
You tell me it's the common solution
Well, you know
You'd better free your mind instead
But if you are still writing functions that return void now
You ain't gonna make it with anyone anyhow
Don't you know it's gonna be
All right
All right
All right
All right, all right, all right
All right, all right, all right
All right, all right
---
Tony Van Eerd
Tony has been coding for well over 25 years, and hopefully coding well for most of that. Previously at Inscriber, Adobe, and BlackBerry, he now enables painting with light at Christie Digital. He is on the C++ Committee. He is a Ninja and a Jedi.
---
Video Sponsors: think-cell and Bloomberg Engineering
Audience Audio Sponsors: Innoplex and Maryland Research Institute
---
Videos Filmed & Edited By Bash Films: bashfilms.com/
CZcams Channel Managed & Optimized By Digital Medium Ltd: events.digital-medium.co.uk
---
CppNow 2024
www.cppnow.org
/ cppnow
---
#boost #cpp #cppprogramming - Věda a technologie
Great talk. "Separating calculating from doing" is a very valuable guideline. It has been in the back of my mind for a while but was never able to express it clearly. Hilarious story with the dog and the fridge, this is something you really see everywhere and it always ends up in a mess :D
Amazing, wise and fun talk with explanation and arguments for presented opinions.
Can't wait to watch part V.
30:31 They are different. If Orientation on the left is a typedef for a basic type (double, for example), it can be stored in a register. On the right, even if it has a single member of that type, it cannot be stored in a register, or passed to a function in a register.
18:22 I like to pass references instead of not nullable pointers, even if that looks strange in that instance. It just makes it clear for the reader that null is not accepted here, because null references are evil. (Although I've heard of a C++ codebase that null-checks references.) In this case, it could probably even be a const ref, since we're just reading from Projector.
He has a point. Seems like Sean Parent only gives talks that leave people silent and then causes a lot of discussion. Also putting Wind waker clips in the middle negates any critique one might have.
Love Sean Parent. Why is the original talk no longer available? How awful. He gave a version at Google which you can find.
I liked the talk. I have one question though, or perhaps an issue I'd like to raise, hopefully the speaker can address it. at 55:52 - "expect it would return the result". Even though this is (personally) preferable, because it makes the code easier to read, doesn't this make it a lot harder to allow for control of memory allocations? That's at least the issue I seem to run into, all the time, when thinking about value semantics or value oriented programming. It ends up being, so many spurious allocations all over the place, _because_ we return results from functions.
I'm not fond of output parameters either, I think they make it a bit "harder" (not harder, really, but it might take longer time) to reason about code, but it does allow for the caller to control what memory is being used, how much gets pre-allocated so on and so forth.
From a "value oriented programming"-perspective, what would be the solution for this?
Interesting talk although I would actually argue this often produces horrible code to read. If I have to jump through 15 layers of functions to find the business logic i'm going to have a much harder time modeling the scope of the program in my head.
You usually want to define a lot of smaller functions but then use them at mostly the same level in kind of a pipeline manner. Deep call graphs are indeed pretty bad