Back to Basics: C++ Smart Pointers - David Olsen - CppCon 2022
Vložit
- čas přidán 28. 11. 2022
- cppcon.org/
---
Back to Basics: C++ Smart Pointers - David Olsen - CppCon 2022
github.com/CppCon/CppCon2022
Smart pointers were one of the many powerful additions to C++11, providing programmers with easy-to-use tools to help manage memory resources and avoid certain kinds of memory errors. This back-to-basics session will give you a solid foundation in smart pointers, explaining what smart pointers are in general and how to use the standard smart pointer types std::unique_ptr and std::shared_ptr. It will present a set of clear guidelines for when and how to use smart pointers. Attendees will leave this session having learned, among other things, how to write code that never leaks memory.
---
David Olsen
David Olsen has more than two decades of software development experience in a variety of programming languages and development environments. For the last six years he has been the lead engineer for the NVIDIA HPC C++ compiler, focusing on running parallel algorithms on GPUs. He is a member of the ISO C++ committee, where he was the champion for the extended floating-point feature in C++23.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
CZcams Channel Managed by Digital Medium Ltd events.digital-medium.co.uk
#cppcon #programming #coding - Věda a technologie
THIS GUY! ... every talk he did i watched so far is worth its time in gold
Wonderful video!!! Very well explained covering lots of issues with usage as well.
This talk is too good, incredible information presented. I have used this talk to sprawl my research and understanding of mentioned topics. Thanks David, this is much appreciated!
Excellent talk, thank you! Appreciate always revisiting some fundamentals.
I’m currently in the process of updating a pre-C++11 codebase and some rules I imposed to myself is:
* Never assert(ptr_parameter); If you find yourself doing this to a parameter, it should be a reference. If necessary, the caller must assert.
* never new and delete (“// transfers ownership” doesn’t cut it)
* For arrays, use container types (e.g. std::vector, std::array) and (custom type) ranges and iterators
Then, any T* is a nullable non-owner pointer to a single object. Exceptions apply when calling library functions I have no control over, but if _my_ function takes/returns a int* it expects/returns a nullable non-owner pointer to a single object.
Excellent talk ! Learnt a lot.
Great talk - thank you for the fundamentals here!
Thank you ! Talk was good, learnt a lot !
48:20 the type-erased nature of shared_ptr deleters can sometimes relieve issues related to multiple heap situations, ensuring an object gets deleted from the heap it was allocated from
What is type-erased, also mentioned in 42:30, where it was mentioned as a resone for unique_ptr having deleter as template parameter and share_ptr a constructor argument for an instance of deleter? Thanks in advance :)
this was great!
Awesome, thank u so much.
Thanks!
6:32 I’d add that a raw pointer should be nullable. If it’s non-owning and points to a single object, if it’s also not supposed to be null, what’s the difference to a reference?
9:29 unique pointer as member of class
The variable length arrays in the examples are ok?
Thankyou
at 33:38 on line 2. "a" gets passed into the thread function's parameter "b". Wouldn't that increment count. There's no red arrow showing increment count on line 2. A bit hazy on this, if anyone would answer, that would be great!
I got the same question haha
I think the compiler optimizes that away (assuming you don't compile with -O0) in this case.
You are right. I missed the increment when the child thread's 'b' is initialized from the main thread's 'a'. I should have noticed that the number of increments and decrements didn't match. The main point of that slide, that the increments and decrements don't introduce data races, is still valid.
nice
if a unique pointer is the same in memory as a raw pointer, does that mean that I can reinterpretcast a raw pointer as a unique pointer and have it call the destructor?
14:02, 29:17 (slightly advanced) note that self-move (e.g. “a=std::move(a);”) is not considered something that move-assignment should guard against. Copy-assignment should typically guard against self-assignment, and this is guaranteed for shared_ptr.
Is this some guideline? Thanks
@@coolwinder yeah since when you move an object, you set the pointer of the other object to nullptr. when you self move you set your object's pointer to nullptr. memory leak.
45:42 another good talk about some nice variations of smart pointers: czcams.com/video/sjLRX4WMvlU/video.html
I'd argue that the first two examples don't need smart pointers.. what's wrong with std::vector??
Sometimes better performance (for creation and destruction*, not access which is the same) and less memory. Plus they signal to everyone that they shouldn't change in size.
*there are exceptions where std::vector outperforms such as when the size is very large or you want to use std::move.
35:38
some member of the committee should be ashamed of their inefficiency. they always use “pursuing perfection” as an excuse, but in fact they spent one three-year after another, and got one half-finished product after another
CppCon 2019 - Back to basics: Smart pointers. By Arthur O'Dwyer. What's the point of repeating the same topic three years later?
so that we eventually get it
Why does your university offers same classes every year while a recording is available?
Topics on the Back to Basics track are often repeated, but the presenter is always different with the expectation that the talks will be different enough that each of them is useful. Arthur O'Dwyer's and my Smart Pointer talks are more similar than I would have preferred. But Mike Shah's and my Concurrency talks are nothing alike and there are benefits to watching both of them.
As already pointed out (yes I know) this same topic was given by Arthur O'Dwyer three years ago. I check these out just in case there's something neat or new discussed.
The audio in this video is terrible I couldn't finish watching it.
Audio seems fine to me.
DId he fr just do an entire presentation reaeding a script
Reading a damn good well prepared script.
pretty perfunctory talk. All the huffing and blowing made it seem that Mr. Olsen was doing it under duress. Maybe let someone with a bit more enthusiasm for the subject do it next time?
Did it? It could be a health issue, or nerves, or something else.
I liked the content. Learnt something useful.
I liked the content. Learnt something useful.
Perhaps he just really wanted to eat those three little pigs.
Great talk IMO.
its smart pointers. It is perfectly understandable to lack enthusiasm on such a basic topic, but someone has to do such entry talks, just so we have an alternative entry point to those zoomer tutorials