Skip to main content
6 events
when toggle format what by license comment
Nov 14, 2013 at 7:13 comment added concept3d thanks for the details, after thinking thoroughly about what you said it totally makes sense. There should only be one owner, and other subscribers ( or sth similar to weak_ptr ). +1.
Nov 14, 2013 at 1:21 comment added Sean Middleditch @concept3d: maybe. I wouldn't count on it being finished soon. I can just say for right now from a few decades of collective experience between me and a few lead engine architects I've spoken to on the matter recently that shared_ptr-like smart pointers tend to cause more headaches than they're worth. A lot of very hard to debug problems can start popping up close to shipping which all boil down to reference leaks (not clearing a shared_ptr when you should have) or destructors being called at the wrong time (objects staying alive too long then being destroyed at a bad time).
Nov 14, 2013 at 0:14 comment added concept3d well I understand. I was thinking to implement my resource managers using shared_ptrs, but things will be clearer if I read your article is it finished ?
Nov 14, 2013 at 0:11 comment added Sean Middleditch @concept3d: I've been working on an article on it; it's hard to sum up. In the end it's just a bad ownership model. Only one object should ever own another; everyone else should be "subscribers" requesting that the owner keep it around, and which should be traceable/debuggable (you should be able to list at any time all active handles to a resource, which you can't do with shared_ptr). It has all the faults of automatic GC in regards to semantics and all the downsides of reference counting in regards to implementation.
Nov 13, 2013 at 20:50 comment added concept3d can you elaborate why C++11 shared_ptr is the wrong model? even with make_shared? is it because of performance or use pattern/syntax ?
Jul 10, 2013 at 3:35 history answered Sean Middleditch CC BY-SA 3.0