2

I have a doubt with boost::shared_ptr.

I have seen this in a destructor (with ptr being a boost::shared_ptr): ptr = boost::shared_ptr< int >( new int ).

Is that ok?. Shouldn't it be ptr.reset(), like stated here: How to intentionally delete a boost::shared_ptr?

Cheers!.

Community
  • 1
  • 1
Adri C.S.
  • 2,909
  • 5
  • 36
  • 63
  • 2
    You have a doubt? Where there is doubt, let me sow faith: It's fine. – Kerrek SB Dec 14 '12 at 09:53
  • Hi, oh divine prophet!. Why is that better than calling `reset()`?. Or is it a matter of taste?. Thanks!. – Adri C.S. Dec 14 '12 at 10:01
  • 1
    It's not better, it's worse. Unless you do want to use that new int, of course. – David Pierre Dec 14 '12 at 10:19
  • Ok!!. Thanks!. How about posting it as an answer so I can accept it? :) – Adri C.S. Dec 14 '12 at 10:21
  • 1
    @AdriC.S.: It's not better, but it's also not incorrect. The point of smart pointer classes (or *any* sane library code for that matter) is that you cannot break anything by using its normal interface. Assignment of smart pointers is perfectly fine (though `reset` is clearer and more direct). – Kerrek SB Dec 14 '12 at 13:33

2 Answers2

4

It depends what you want to do with ptr afterwards.

If you need to reassign it to point to a new value, then that's what the code does. If you need to explicitly invalidate it, then that's what reset() does. If it's a class member that will be implicitly destroyed by the destructor, then there's probably no need to do anything, unless you have some weird destruction order requirements.

Without more context, it's impossible to say which is correct.

UPDATE: since you say this is not actually in a destructor, but a member function intended to leave the object in a weird half-destroyed state, it depends on how that weird state is specified. If it requires an empty pointer, then reset it; if it requires a valid pointer, but not to whatever was previously being shared, then reassign it. Better still, eliminate this state entirely to give the object stronger validity guarantees.

Mike Seymour
  • 249,747
  • 28
  • 448
  • 644
  • Hi!. Well, for what I've seen, the shared pointer is used inside a class. So when the instance of that class is destroyed, the shared pointer disspears, since each instance has its own shared pointer. The new int line is used in a method called finalize, that's called when the object is destroyed. – Adri C.S. 4 secs ago – Adri C.S. Dec 14 '12 at 10:37
  • @AdriC.S.: So you have a member function that's intended to put the object into some weird undead state, separately from the destructor? In that case, only the lunatic who designed that class can say what the post-conditions of that function are supposed to be. In a sane design, destruction would be handled by the destructor, and you wouldn't need to do anything explicit to release a `shared_ptr` member. – Mike Seymour Dec 14 '12 at 10:41
  • Yep, there's the `finalize` function that "clears" the shared pointer and deletes other normal pointers used inside the class. The destuctor is declared... but empty: `~ThatClass::ThatClass(){}`. – Adri C.S. Dec 14 '12 at 10:45
  • @AdriC.S.: If it's truly meant to "clear" the object without actually destroying it, then you do indeed want `reset()`. – Mike Seymour Dec 14 '12 at 10:49
  • Mike, thnaks for your answer. Just one more question, what if the object is meant to be destroyed?. – Adri C.S. Dec 14 '12 at 10:57
  • 1
    @AdriC.S.: When the object is destroyed, there's no need to do anything explicit with `shared_ptr` members; they will be implicitly released by their own destructors. You only need to delete anything you're managing with raw pointers - which you really shouldn't be doing at all, ever. – Mike Seymour Dec 14 '12 at 10:59
1

ptr = boost::shared_ptr< int >( new int ) will swap the internal value with a new int that you don't want to use by calling the boost::shared_ptr constructor... in his destructor.

ptr.reset() will swap the internal value with nothing, it's better as mentioned in the post you linked

Prasad Jadhav
  • 5,090
  • 16
  • 62
  • 80
floppy12
  • 1,045
  • 6
  • 12