 |
Web Hosting by Netfirms | Free Domain Names by Netfirms |
|
|
|
Extending The Standard Library
When storing data we are encouraged to play nicely, be politically correct and use the STL, however, there are a number of areas where the STL container library frankly does not help a great deal. One of these is storing pointers. It has given us a basic smart pointer type that cannot be stored in containers and containers that do not have specific handling for pointers.
Storing pointers directly can lead to ambiguities of ownership that can cause anything from resource leaks to access violations.
Will the Developer remember to delete them?
Should the lifetime of a pointer be handled by the program and if so how?
Much store is made of guarantees. Guarantees are difficult to achieve with something as transient as a pointer, either the pointer is hidden totally, access and usability are sacrificed, or a limited guarantee is achieved. A number of options are available for resource handling and a number of smart pointer types available to express them.
Wouldn’t it be simpler, on those occasions where it is appropriate, to have a container that calls delete on all of its’ pointers as it goes out of scope a “smart container”. In that case the primary guarantee will be “This class WILL clean up your resources when it is destroyed, no matter what.” The maximum extension of flexibility that can be offered to the user of the contained class can only be “you can manage its’ creation and use within these limits”. This is a stronger guarantee than that of reference counting and other similar methodologies.
So when would a class like this be useful?
When strictly limited resources are being handled.
Examples could be; Persistent Object Brokers, Sessions, Mutexes, Device contexts etc. etc.
So what do we want from this smart container?
It needs to be usable in the same way as the STL and similarly generic.
It needs to be extensible to allow it to be used specifically.
It needs to be flexible and provide a number of default options to make it quick and easy to use.
After much experimentation from trying a container of hidden generic smart pointers (yes, seriously I did!!!) to private inheritance, I have plumped on a policy based template class. Policy based development allows a flexible approach to class design. Policies can be “plugged-in” by the user of the class to provide a number of design options which offer flexibility without having to program it each and every time. Added to which they’re dead cool.
Here is an example. Exception handling etc. has been omitted for clarity and through laziness.
by Robert Mitchell 15th April 2003