Re: std::auto_ptr and const correctness
On 12 Mai, 15:26, jens.muad...@googlemail.com wrote:
Hi,
in the project I am working on, std::auto_ptr is used to implement
move semantics and sometimes to store pointers in classes which cannot
be copied. When I analyzed some old code, I found a flaw in the
definition of std:.auto_ptr which breaks const-correctness of the
code:
#include <memory>
class X
{
public:
void f() {i=42;}
int i;
};
[...]
class Test
{
public:
void f() const
{
autoPtr->f();
X* x = autoPtr.get();
x->f();
}
[...]
std::auto_ptr<X> autoPtr;
AutoPtr<X> customAutoPtr;
};
When this is compiled, the compiler only reports an error for method
Test::g(), not for Test::f()
Inside Test::f the member object autoPtr is const and you're asking
yourself why get() returns a non-const pointer. Correct?
[...]
Additionally, the standards specifies std::auto_ptr to have the
following members:
// 20.4.5.2 members:
X& operator*() const throw();
X* operator->() const throw();
X* get() const throw();
X* release() throw();
void reset(X* p =0) throw();
Is there any reason why the methods are specified const but return a
non-const pointer? I know that std::auto_ptr is deprecated, but this
looks as a serious flaw.
This is not a flaw. It is intentional. The "smart" pointers behave
just like their raw pointer counterparts in this respect: top-level
constness only means you can't change the pointer but you can still
change the pointee through that pointer ("pointer semantics").
If this is not what you want you can work around it by using your own
AutoPtr flavour with different semantics or keep using auto_ptr and
write
void f() const
{
autoPtr->f();
X const* x = autoPtr.get(); // <-- note the const here
...
}
instead. The good thing is that your auto_ptr object is a *private*
member. So, you can still control access via const-overloaded member
functions just like it is done inside a vector:
template<typename T>
class vector {
T* pointer; // top-level constness doesn't protect the pointees
public:
...
T const& operator[](int idx) const {return pointer[idx];}
T & operator[](int idx) {return pointer[idx];}
...
};
Even though "pointer[idx]" is in both cases a reference-to-non-const
(assuming T is non-const) it is converted to a reference-to-const in
the first function because the array's elements are logically "a part
of" the vector object.
It depends on what you want. Sometimes it's the "a part of" semantics
and sometimes it's the "pointer semantics".
Cheers!
SG
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]