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!
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.
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 :)
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?
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.
@@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!
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.
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
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.
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.
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 ....
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.
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.
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?
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
![ปฏิเสธไม่ไหว (Crush on you) - LIPTA feat. No One Else [Official MV]](http://i.ytimg.com/vi/NBw1jF342vw/mqdefault.jpg)
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
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.
@@Bolpat use static_assert instead of assert if possible. Unnecessary runtime hit by RTTI.
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.
Great talk - thank you for the fundamentals here!
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?
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.
9:29 unique pointer as member of class
The variable length arrays in the examples are ok?
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.
this was great!
Thankyou
45:42 another good talk about some nice variations of smart pointers: th-cam.com/video/sjLRX4WMvlU/w-d-xo.html
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
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.
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.
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 ....
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.
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.
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