Timeline for Should a class which has a method to create object A also implement a method to delete A?
Current License: CC BY-SA 4.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 30, 2018 at 4:01 | vote | accept | ocomfd | ||
| Jul 25, 2018 at 16:07 | comment | added | Basilevs | Shared_ptr is not convertible back to unique_ptr, so that would reduce flexibility. Added costs are unnecessary here. We can store any pointer anywhere we want. We don't LOSE when we MOVE. I seem to misunderstand your questions. Could you expand on each and explain, why an obvious answer is not suitable? Consider creating dedicated questions (after searching for duplicates). | |
| Jul 25, 2018 at 15:59 | comment | added | Caleth | @LewisPringle no, a reference is not an "unsmart" pointer. it is most closely a constant pointer (not to be confused with pointer-to-constant), but it explicitly does not deal with the lifetime of the referant | |
| Jul 25, 2018 at 15:52 | comment | added | Lewis Pringle | At the end of the day, you must decide if you want the object to be referenced in one place or many places. And in GUI programming, a button will likely be referenced in multiple places. | |
| Jul 25, 2018 at 15:51 | comment | added | Lewis Pringle | @Basilevs - embarresed, but I didn't realize unique_ptr<T> was (move convertible) to shared_ptr ;-) Thanks for that tip! But still - I think the idea is not a good idea. If your thought is that you are going to convert it to a shared_ptr<> - why construct it as a unique_ptr? And the one place you are going to store it? What do you declare it as? Declare it as unqique_ptr<> and the first time you convert it to a shared_ptr, you LOSE that unqiue_ptr reference (because it has to be moved). | |
| Jul 25, 2018 at 15:51 | comment | added | Basilevs | @LewisPringle when you can avoid using pointers of any kind, you definitely should. In OP's case pointers are only required due to legacy API. | |
| Jul 25, 2018 at 15:49 | comment | added | Lewis Pringle | @Caleth if you are going to use references, you may as well not be using smart pointers of any kind. The reference is an unsmart pointer. | |
| Jul 25, 2018 at 15:23 | comment | added | Basilevs | @LewisPringle unique_ptr is convertible to shared_ptr and does not have it's added cost of atomic reference counting. | |
| Jul 25, 2018 at 14:44 | comment | added | Caleth | @LewisPringle no, you have exactly one place which owns the std::unique_ptr<button>, and a bunch of other places that reference it ( button &) | |
| Jul 25, 2018 at 13:35 | comment | added | Lewis Pringle | shared_ptr<> would be a better fit here than unique_ptr<>, since its not unlikely the ptr would be needed in more than one place (due to how gui frameworks usually work - like list of buttons associated with a page, list of things with callbacks etc). | |
| Jul 25, 2018 at 4:20 | history | edited | Basilevs | CC BY-SA 4.0 | added 236 characters in body |
| Jul 25, 2018 at 4:14 | history | edited | Basilevs | CC BY-SA 4.0 | deleted 12 characters in body |
| Jul 25, 2018 at 4:08 | history | answered | Basilevs | CC BY-SA 4.0 |