I think this is the third video I've watched on Smart Pointers this week (maybe the sixth or seventh if you count small ones!!) and it is the first one that called to attention WHY the method on weak pointer is called .lock() and why it is necessary!!! This is what I would expect from this author/lecturer. There are talks and books I ignore because the people don't know enough to be worth trying to learn from, there are the talks and books I am scared of because the people are geniuses who know so much I think I can't keep up with them or follow them, and those I follow semi-religiously. I thought this author was in category two until I was better at C++ than I felt I was, but this talk just moved him into camp three. When he talks about C++ I will act like my dog does when I talk about food and walks!
Second comment. After watching several other videos, I literally had nightmares wondering how shared pointers and weak pointers MUST work to actually function correctly...surely they couldn't be as simple an implementation as I imagined from the other talks or they wouldn't work reliably. At ~18:00 this video shows exactly the machinery that makes shared_ptr/weak_ptr safe for human consumption. Of course it has to be there, it wouldn't be safe to use otherwise. I don't personally save time by watching/reading material that omits such stuff because "just not thinking about it" is only an option until I go to sleep. This level of talk literally prevents nightmares for me.
Calling release() after passing a unique_ptr to a function by reference can leak resource if the function did not take the ownership. release() sets the pointer to nullptr and returns raw pointer which is NOT deleted. It is up to the code which takes that pointer to call delete! What you might have in mind is to call reset() function which deletes owned pointer and reset the unique_ptr to nullptr
There are multiple good talks on this that seem to disagree on whether it is better to use weak_ptr or shared_ptr for back references from owned objects. Arthur O'Dwyer thinks it is fine to use raw pointers from B back to A. I guess it depends on whether you believe that you can ever get into a state where B exists independent of A, doesn't it? I guess in general, if you need to refer to something that may or may not be there anymore, and if they aren't, that's okay, but you need to find out, and if they are then that is your guy -- you need a weak pointer. Raw pointers should NEVER be allowed to dangle, so they are ideal as long as you are an observing pointer to something that you know hasn't disappeared since, and a very serious error otherwise.
59:29 the audio says "Shared pointers were implemented and designed to have no performance overhead, end of discussion." Of course, we mean unique pointers in that sentence.
Don't use raw pointers because of potential memory leaks, if you're not careful. Use smart pointers instead and deal with overhead, copying, moving, multithreading, custom deleters, actual uniqueness, code smells, new casting, bunch more deathtraps and... potential memory leaks if you're not careful. Brilliant!
~57:16 slide 90. I don't understand the call to .release(). If it somehow still had ownership when we got to that point, calling .release() and throwing away the value would be a memory leak. If it didn't, I am also not sure what it buys us, calling .release() on a moved-from object. I think we are rushing a bit as we come to the end of the presentation, and the normally very careful wording may have slipped. We definitely need a good style guide for all of these things, that is agreed for sure.
I guess you were referring to the rvalue reference case when the actual move is not guaranteed. It was a general note, with unique_ptr the move has to take place as there is no copy construction allowed. Good question though.
@@panmanio Exactly. If function takes pointer by value, on the calling side pointer definitely will be moved, and there is no sense to call release()/reset() after calling such function.
On slide 29, ~11:33, I am not sure what is going on with the lines showing gp->print() and gp.use_count() gp just contains null at this point, right? Was this a typo or is it supposed to show us something about the default behavior of a new created shared_ptr?
On slide 57 (29:38) Do we have 0 or 1 weaks ? On slied 90 Is there memory leak after invoking release with "&&" sink, when ownership is not lost there (reset method seems to be better here than release) ?
Great video, thanks for sharing. i still got a problem tough.. i'm trying to allocate a private member vector of unique_ptr to a base class object ( std::vector m_objects ; ) and than to pushback derived classes into it trough a void function that gets nothing and returns nothing but it knows the vector member in the private section of the class because the cpp file belongs to its header file so i use ( m_objects.push_back(std::make_shared (); ) but i always get these linkage errors 2019 and 1120 and i don't know what to do anymore..
On passing shared pointers by reference, someone commenting on some other video raised the spectre of "if you do that, you can lose the reference to the object in question"...I didn't see how that could happen, but they seemed sure. Is there some race condition or corner case where passing a shared_ptr by reference isn't safe? I do understand some people think they shouldn't be appearing as parameters in calls at all, but only as part of another object, etc. -- but I don't see any *risk* in passing them by reference, only that someone else thought there was some danger in doing so.
I love the semantics that smart pointers introduce. However, the syntactic support is just too weak. You either have to put templates everywhere, use template arguments everywhere or define a ridiculous amount of types to get something that gets you to readable code. Comparing "object*" to "std::unique_ptr" one can clearly see this leads to unreadable code as soon as you need to use a collection. You could create a using alias, but now you have a type that is highly non-standard and will differ from project to project if not from one file to another. This is not a terribly high price to pay for the safety that smart pointers bring, but I, for one, would be a lot happier if they were a language feature, not library code. std::unordered_map is kind of ridiculous and if you don't want to introduce obscure types, you will have to put up with code like that. Hopefully modules will at least solve the sprinkling of namespaces everywhere. unordered_map would be a lot cleaner and more readable (obviously $ for being an expensive shared_ptr :-))
I do not think it is so big problem. I actually think it is good thing. You usually have to use smartpointers in API only if you are dealing with ownership. Which is so much important factor that it deserves a bit verbosity. I am glad that writing std::shared_ptr is so verbose, it makes people think about whether it is not better to pass raw pointers or references where they do not deal with transferring ownership. Btw. the worst kind of legacy code is the one which uses std::shared_ptr everywhere...
Totally agree. Also, the memory leak danger is only a complicated problem when you use RAII or individual allocations. Join the cohiesion/group allocation side and together we'll rule the galaxy :)
I think this is the third video I've watched on Smart Pointers this week (maybe the sixth or seventh if you count small ones!!) and it is the first one that called to attention WHY the method on weak pointer is called .lock() and why it is necessary!!! This is what I would expect from this author/lecturer. There are talks and books I ignore because the people don't know enough to be worth trying to learn from, there are the talks and books I am scared of because the people are geniuses who know so much I think I can't keep up with them or follow them, and those I follow semi-religiously. I thought this author was in category two until I was better at C++ than I felt I was, but this talk just moved him into camp three. When he talks about C++ I will act like my dog does when I talk about food and walks!
Second comment. After watching several other videos, I literally had nightmares wondering how shared pointers and weak pointers MUST work to actually function correctly...surely they couldn't be as simple an implementation as I imagined from the other talks or they wouldn't work reliably. At ~18:00 this video shows exactly the machinery that makes shared_ptr/weak_ptr safe for human consumption. Of course it has to be there, it wouldn't be safe to use otherwise. I don't personally save time by watching/reading material that omits such stuff because "just not thinking about it" is only an option until I go to sleep. This level of talk literally prevents nightmares for me.
Calling release() after passing a unique_ptr to a function by reference can leak resource if the function did not take the ownership. release() sets the pointer to nullptr and returns raw pointer which is NOT deleted. It is up to the code which takes that pointer to call delete!
What you might have in mind is to call reset() function which deletes owned pointer and reset the unique_ptr to nullptr
Thank you very much for sharing! Very very interesting presentation.
There are multiple good talks on this that seem to disagree on whether it is better to use weak_ptr or shared_ptr for back references from owned objects. Arthur O'Dwyer thinks it is fine to use raw pointers from B back to A. I guess it depends on whether you believe that you can ever get into a state where B exists independent of A, doesn't it? I guess in general, if you need to refer to something that may or may not be there anymore, and if they aren't, that's okay, but you need to find out, and if they are then that is your guy -- you need a weak pointer. Raw pointers should NEVER be allowed to dangle, so they are ideal as long as you are an observing pointer to something that you know hasn't disappeared since, and a very serious error otherwise.
59:29 the audio says "Shared pointers were implemented and designed to have no performance overhead, end of discussion." Of course, we mean unique pointers in that sentence.
Don't use raw pointers because of potential memory leaks, if you're not careful. Use smart pointers instead and deal with overhead, copying, moving, multithreading, custom deleters, actual uniqueness, code smells, new casting, bunch more deathtraps and... potential memory leaks if you're not careful. Brilliant!
Very well explained. Thank you for sharing.
~57:16 slide 90. I don't understand the call to .release(). If it somehow still had ownership when we got to that point, calling .release() and throwing away the value would be a memory leak. If it didn't, I am also not sure what it buys us, calling .release() on a moved-from object. I think we are rushing a bit as we come to the end of the presentation, and the normally very careful wording may have slipped. We definitely need a good style guide for all of these things, that is agreed for sure.
great explanation. thank you.
57:00 Why he propose to release() the pointer? I think there must be reset(), because release leads to memory leak.
There is no leak after std::move. The ownership is passed, release is fine.
I guess you were referring to the rvalue reference case when the actual move is not guaranteed. It was a general note, with unique_ptr the move has to take place as there is no copy construction allowed. Good question though.
@@panmanio Exactly. If function takes pointer by value, on the calling side pointer definitely will be moved, and there is no sense to call release()/reset() after calling such function.
This is a mistake and a memory leak. So yes it must be reset().
On slide 29, ~11:33, I am not sure what is going on with the lines showing gp->print() and gp.use_count()
gp just contains null at this point, right? Was this a typo or is it supposed to show us something about the default behavior of a new created shared_ptr?
On slide 57 (29:38) Do we have 0 or 1 weaks ?
On slied 90 Is there memory leak after invoking release with "&&" sink, when ownership is not lost there (reset method seems to be better here than release) ?
Great video, thanks for sharing. i still got a problem tough.. i'm trying to allocate a private member vector of unique_ptr to a base class object ( std::vector m_objects ; ) and than to pushback derived classes into it trough a void function that gets nothing and returns nothing but it knows the vector member in the private section of the class because the cpp file belongs to its header file so i use ( m_objects.push_back(std::make_shared (); ) but i always get these linkage errors 2019 and 1120 and i don't know what to do anymore..
On passing shared pointers by reference, someone commenting on some other video raised the spectre of "if you do that, you can lose the reference to the object in question"...I didn't see how that could happen, but they seemed sure. Is there some race condition or corner case where passing a shared_ptr by reference isn't safe? I do understand some people think they shouldn't be appearing as parameters in calls at all, but only as part of another object, etc. -- but I don't see any *risk* in passing them by reference, only that someone else thought there was some danger in doing so.
Thank you, a great video!
I love the semantics that smart pointers introduce. However, the syntactic support is just too weak. You either have to put templates everywhere, use template arguments everywhere or define a ridiculous amount of types to get something that gets you to readable code. Comparing "object*" to "std::unique_ptr" one can clearly see this leads to unreadable code as soon as you need to use a collection. You could create a using alias, but now you have a type that is highly non-standard and will differ from project to project if not from one file to another. This is not a terribly high price to pay for the safety that smart pointers bring, but I, for one, would be a lot happier if they were a language feature, not library code. std::unordered_map is kind of ridiculous and if you don't want to introduce obscure types, you will have to put up with code like that. Hopefully modules will at least solve the sprinkling of namespaces everywhere. unordered_map would be a lot cleaner and more readable (obviously $ for being an expensive shared_ptr :-))
I do not think it is so big problem. I actually think it is good thing. You usually have to use smartpointers in API only if you are dealing with ownership. Which is so much important factor that it deserves a bit verbosity. I am glad that writing std::shared_ptr is so verbose, it makes people think about whether it is not better to pass raw pointers or references where they do not deal with transferring ownership. Btw. the worst kind of legacy code is the one which uses std::shared_ptr everywhere...
Totally agree. Also, the memory leak danger is only a complicated problem when you use RAII or individual allocations. Join the cohiesion/group allocation side and together we'll rule the galaxy :)
Videos starts at 1:40
wack
Smart pointers are great and anyone who uses garbage collection must be a really crappy programmer
Tbf, garbage collected languages force you to use the garbage collector because they don't offer you the choice of pointer management