auto_ptr<char> s;
// Do something...
s = auto_ptr<char>(new char[100]);
The reason this is not a good idea is rather subtle, but basically it's due to the fact that the temporary object is not a reference to an object, it's an object, and you can't really make a reference to a temporary object like that. At least it's pretty bad form... It's a similar situation where you can't use a temporary object as a parameter for a non-const reference formal parameter to a function.
The way to do this is of course:
auto_ptr<char> s;
// Do something...
s.reset(new char[100]);
This led to some other code being affected, specifically code where methods had the following type of signature:
auto_ptr<char> Func() {
auto_ptr<char> t(new char[10]);
// Do something to set t to something
return t;
}
This looks neat, and is apparently a good idea to ensure that allocated objects are automatically delete'd as part of the auto_ptr destructor. However, this messes things up in other parts of the code since once again for similar reasons as above.
The resulting pattern rule is:
- Always return a pointer, not an auto_ptr, when an object is allocated.
- Never store a pointer, always wrap it in a auto_ptr object when it's kept around for more than passing on in the same statement.
I'm a strong believer in what I call "code policy". Code policy is about formulating rules of coding, a bit like design patterns but more generic small snippets of wisdom accumulated through experience. I use probably 50 - 100 such "code policies" whenever I write code, and it's certainly been extremely useful. It takes the burden out of making many small decisions, and I may start document them for peer review in the future - that could be fun!
