4 ms·
Just to be clear, the replacement for auto_ptr is unique_ptr, not shared_ptr. The vast majority of allocated objects have unique ownership semantics, not share
by Negitivefrags 14y ago
Just to be clear, the replacement for auto_ptr is unique_ptr, not shared_ptr.
The vast majority of allocated objects have unique ownership semantics, not shared. If you use shared_ptr everywhere, it's far too easy for your design to degenerate into object soup.
- dmm 14y agoIf the ownership semantics are clear, scoped_ptr works too.
- TillE 14y ago> If you use shared_ptr everywhere, it's far too easy for your design to degenerate into object soup. You mean that it's usually better design to have only one "owner" of an object? That's true. It's worth noting that shared_ptr is also necessary for containers, so you might get into a habit of using it even if you're not creating multiple references.
- Negitivefrags 14y agoNo it isn't. unique_ptr works very well in containers.
- eliben 14y agoNot only. Over-use of shared_ptr is sloppy, and may cause reference leaks which are no easier to solve than memory leaks. Its use is recommended only when sharing semantics are actually required.
- shrughes 14y agoshared_ptr isn't necessary for containers, it's only necessary for bad containers. Edit: Of course I'm being a bit stupidly snarky here, obviously if you have a standard container you need a shared_ptr, or an intrusive_ptr, or some other pointer, the moral of the story is that std containers aren't good for holding owned pointers in C++03. I don't think boost ptr_containers are particularly good either, but that's mostly because of the huge cost of putting the string '#include "boost/' in your code.
- deleted 14y ago[deleted]