Quote:Original post by sipickles
I've been persuaded to use boost::shared_ptrs instead of standard pointers but have wasted alot of time with these time-saving helpers.
Since I think I was the one who suggested managing your resources via shared_ptr, I should probably comment on this :)
If you're new to smart pointers and/or the Boost libraries it might take a little time to get used to the semantics and the finer points of usage, but I'm sure it will pay off in the long run.
Problems with passing 'standard' raw pointers around include:
1. You have to remember to delete them.
2. You can delete them at any time, even if 'live' pointers to the same object still exist elsewhere in the program.
3. There's no way to check a non-null pointer for validity - you just have to dereference it and hope for the best.
I think the 'wrapper' class you had in place previously was intended to address some of these problems, but shared_ptr is tried and tested and addresses all of the problems listed above. (Just to be thorough, you can still get yourself in trouble through careless use of the get() function, but this more or less falls into the category of 'deliberate misuse'.)
Also, as noted above shared_ptr shares similar semantics with raw pointers in several important respects. You can check them for validity via Boolean expressions, and you can have a 'null' shared pointer object that represents an 'empty' or unassigned pointer.
shared_ptr offers additional useful functionality as well; for example, at any time you can query a pointer to find out how many times the held object is referenced throughout the program (provided you've used smart pointers consistently).
Boost also has a few other useful smart pointer classes that 'fill in the gaps', so to speak. weak_ptr can be used to break cyclic dependencies, and scoped_ptr can be used where sole ownership is desired. (However, AFAIK scoped_ptr cannot easily be used with resources such as the DirectX effects under discussion in your previous thread, as it does not offer support for custom deleters).
So yes, when adopting a new tool there will probably be a little 'bump' and a little extra time spent implementing features that may at first seem like they were 'easier' the old way. Nevertheless, management of dynamically allocated resources via smart pointers represents the current best practice in C++ (or so I gather - I hope the resident gurus will correct me if I'm wrong in this respect), and should be preferred over the use of raw pointers where possible. In the end, it should save you more time (in terms of easier maintenance and fewer bugs) than it costs.