Back to Basics: C++ Smart Pointers - David Olsen - CppCon 2022
HTML-код
- Опубликовано: 25 авг 2024
- cppcon.org/
---
Back to Basics: C++ Smart Pointers - David Olsen - CppCon 2022
github.com/Cpp...
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
RUclips Channel Managed by Digital Medium Ltd events.digital...
#cppcon #programming #coding
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!
THIS GUY! ... every talk he did i watched so far is worth its time in gold
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, thank you! Appreciate always revisiting some fundamentals.
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 :)
Wonderful video!!! Very well explained covering lots of issues with usage as well.
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?
Great talk - thank you for the fundamentals here!
Excellent talk ! Learnt a lot.
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.
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.
Thanks!
Awesome, thank u so much.
9:29 unique pointer as member of class
this was great!
The variable length arrays in the examples are ok?
Thankyou
45:42 another good talk about some nice variations of smart pointers: ruclips.net/video/sjLRX4WMvlU/видео.html
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?
No. Don't try to do that. It won't work. A unique_ptr probably has the same memory layout as a raw pointer, but that is not guaranteed. Doing a reinterpret_cast does not create an object, so the destructor of the unique_ptr will not be run. If you have a raw pointer and you want its memory to be freed automatically, define a unique_ptr variable with the right lifetime and pass the raw pointer to the constructor.
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
nice
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.
std::vector could have been used in those examples, but I don't see it as the best solution. std::vector can fix some of the memory management problems as smart pointers. But std::vector also has all the semantics of a resizable array. Sometime you don't want that or need all that extra stuff. In the first two examples, all that was needed was to automatically free the memory. std::unique_ptr does exactly that, and nothing more, so it is the best fit for those situations.
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.
THIS IS ALL A WASTE OF TIME JUST SWITCH TO RUST OR PYTHON where memory is automanaged for you .... WHY YOU wasting your time attempting to manage stuff that can be automated ....
DId he fr just do an entire presentation reaeding a script
Reading a damn good well prepared script.
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.
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