Boost logo

Boost :

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2006-03-11 06:20:34


On Friday 10 March 2006 00:12, Ralf W. Grosse-Kunstleve wrote:
> --- Sebastian Redl <sebastian.redl_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk