On Friday 10 March 2006 00:12, Ralf W. Grosse-Kunstleve wrote:
--- Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
Your const parameter is a promise that you won't modify the parameter, but then you go ahead and do it anyway. You should make the parameter non-const, like the GNU C++ library does with auto_ptr: auto_ptr(auto_ptr& __a) throw() : _M_ptr(__a.release()) { }
The problem is that my code doesn't compile (g++ 3.4.2) if I remove the "const". I've tried adding the throw() but that didn't do it. I see there is also an auto_ptr_ref<> in the g++ library, but I don't know if this is what does the trick. Could one of the C++ gurus please explain?
The problem is that if a function returns an object, that object is not an lvalue and thus doesn't bind to a non-const reference - therefore, you can't initialise another of your smart pointers with it. auto_ptr recognises that problem and provides a conversion to an auto_ptr_ref and a constructor taking an auto_ptr_ref. In other words, this auto_ptr_ref builds a bridge between the two auto_ptrs. I think there are at least two ways this is implemented, either by storing the raw pointer from release() inside the auto_ptr_ref or by storing a pointer to the auto_ptr inside it. I'm not sure if it makes much difference, I consider auto_ptr_ref an implementation detail anyways, even though the standard does define it. Just curious, but is there a valid reason to use auto_ptr_ref directly? Uli