The requirements for an object in a container is that it is copy constructible.
The implication of something being copy constructible is that the two objects (constructed one and the one you copied from) are equivalent.
When you are copying an unshared smart pointer, after copying one has a valid pointer and one has a null pointer, so it breaks this equivalency.
If you can work around this, then feel free to use the standard containers.
Putting limitations on the types used is part of the price to pay for using templates - I can't really comment on the exact implications of not having this limitation, it is pretty low level in the standard library and I expect makes robust implementation very difficult (that's a guess!)
The boost libraries are often thought of as c++ in waiting ... parts of it will hopefully become standard at the next revision and many, if not most, of the people working on it are on or alfiliated with the c++ standards comittee.
In addition, a smart pointer could be a real killer if you find a bug in it later on ... there is a lot to be said for using something
tried and tested:
Code:
SmartPtr operator=( SmartPtr<T>& other ) {
if ( this != &other )
reset( other.release() );
return *this;
}
If I write this:
Code:
SmartPtr<GameMode> p(new BattleMode);
SmartPtr<GameMode> q;
q = p;
Now what happens to q?
And the pointer from p?
In your assignment operator you have returned by value ...
...calling your 'copy constructor', which in turn has called other.release() and ... OUCH!
q.ptr is now 0
I sympathise with the issues of different libraries - that's just c++ for you
But if there was one external library to use, I would take boost and most of the library is actually just header files so it is pretty easy to use and as such doesn't need to be included in a distribution (other than source code!)