0

I have read a bunch about smart ptr, and have decided to use intrusive_ptr with my own implementation for reference counting.

Said that, I have to face now another problem, how to solve reference cycles taking into account weak_ptr can't be used with the auto_ptr class.

Will it be a good thing to resolve the cycles using raw pointers where weak references should be stored? The consecuences of this are that if the strong reference is deleted weak references will not be notified/zeroed, but I think that arquitecting correctly the dependencies it could be a good option, but I could be wrong here.

Could anybody give any opinion about this?.

Notbad
  • 5,936
  • 12
  • 54
  • 100
  • 2
    Your questions is vague. In your particular scenario, do you actually need the capabilities that `weak_ptr` provides, or will a dumb pointer suffice? (Namely, do you need the ability to test whether a non-owning pointer is valid?) If you answer that question, then you have the answer to the question you've asked. – James McNellis Dec 31 '11 at 22:43
  • What does "arquitecting" mean? – Jesse Good Dec 31 '11 at 22:45
  • @Daniel Thanks. In Spanish and Portugeuse, that seems to be how to spell "architect". – Jesse Good Dec 31 '11 at 23:58
  • Why are you using intrusive_ptr, and why do you have cycles in your reference graph? – bdonlan Jan 01 '12 at 01:46
  • @JamesMcNellis: I'm looking for a way to minize memory leaks but using a smart pointer without heap allocs. Answering the weap_ptr question, I think it is dangerous to not be able to know when refrences to a main/strong pointer are not valid because the main pointer was deleted. I know that being careful this can be minimized but I would like to use a more authomatic method, this is why I have been looking into smart ptr. – Notbad Jan 01 '12 at 12:22
  • @bdonlan: As I said below, I'm using intrusive and not shared_ptr mainly because I found it difficult to use for a starter in the smart ptr world. Another reason is because I mainly use C++ for games and don't like the heap allocations (Yes, I know I wouldn´t be trying to optimize in advance, but I don't really like heap allocs :D). In the other hand it is not supposed to be intrusive but I'm forced to derive my class from the enable_shared_from_this if I want to create shared_ptr from this. – Notbad Jan 01 '12 at 12:43
  • @bdonlan: About the cycles, I have some situations where is a bit difficult to know who must really own the allocated memory, but After thinking a bit more about it I think I could get rid of them making some asumptions and using weak references. – Notbad Jan 01 '12 at 12:49

1 Answers1

1

Just use shared_ptr. It's easier to use, and works with weak_ptr which you mentioned. Maybe someday you'll find a case where you want to use intrusive, but until then, keep it simple.

John Zwinck
  • 239,568
  • 38
  • 324
  • 436
  • At a first glance I used shared_ptr, but it seems a bit hacky to me. You have to dereive your class from enable_shared_from_this if you want to pass this, double deletion pointers can be really easy to create, difficulty knowing when a new reference counter will be created, etc... I'm not saying shared_ptr is not a good option, but I found it difficult to fully get the grasp of it, so, I prefered going with a more easier solution like intrusive_ptr. Perhaps it wasn't a good decision. – Notbad Jan 01 '12 at 12:35
  • 1
    The grass is always greener on the other side, I guess. From where I sit, intrusive_ptr is not nearly as easy to use as shared_ptr. By the way, if you use boost::make_shared<>() you can get just one heap allocation rather than two with shared_ptr. And you may want to look at pools too, before giving up on shared_ptr. You can see how some people use that combination here: http://stackoverflow.com/questions/2911154/custom-pool-allocator-with-boost-shared-ptr – John Zwinck Jan 01 '12 at 13:49