Re: auto_ptr vs. boost shared_ptr
In article <1153301658.835468.72190@m73g2000cwd.googlegroups.com>,
"kanze" <kanze@gabi-soft.fr> wrote:
One can not copy a unique_ptr:
unique_ptr<int> u1(new int(1));
unique_ptr<int> u2(u1); // compile time error
However one can *move* from a unique_ptr using move syntax:
unique_ptr<int> u2(move(u1)); // ok
assert(u1.get() == 0);
assert(*u2 == 1);
I'm not sure how this works. How do you use it as a return
value? Or a parameter? As a parameter, I can always pass it
as a non-const reference, I suppose. But this means that the
client cannot pass a temporary: I have a lot of code along the
lines of:
messageQueue.send(
std::auto_ptr< Message >( new Type1Message( args ) ) ) ;
And of course, messageQueue.receive() returns an auto_ptr by
value, since it no longer has a copy to refer to.
unique_ptr is a small part of a larger proposal: the rvalue reference -
a language change. Included in the language changes is (informally
speaking) anywhere copy elision is current legal, consider the source of
the "copy" to be an rvalue instead of an lvalue, thus invoking a move
constructor if it exists, in preference to a copy constructor (or just
elide the move constructor as you would have the copy constructor).
So, one can return moveable but non-copyable objects from functions as
long as the source is a non-cv-qualified auto object with the same type
as the return:
std::ifstream
find_and_open_file(const std::string& filename)
{
std::ifstream the_file;
// find it and open it
return the_file; // moves, not copies out.
// This retains the invariant that only
// one ifstream object refers to the
// physical file.
}
The move will probably be elided anyway with most modern compilers. But
it is still logically a move, not a copy.
Similarly you can pass by value, but only from rvalue arguments (if they
are not CopyConstructible):
void process_a_file(std::ifstream input);
void foo()
{
std::ifstream a_file(/*...*/)
process_a_file(a_file); // compile time error,
// ifstream not CopyConstructible
}
void foo()
{
std::ifstream a_file(/*...*/)
process_a_file(move(a_file)); // ok
// a_file no longer refers to the file here
}
(And all move really does is convert the lvalue to an rvalue?)
Precisely. From:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html
template <class T>
typename remove_reference<T>::type&&
move(T&& a)
{
return a;
}
(should be inlined in any commercially viable implementation)
Sounds good. (The next obvious question is: where can I access
an implementation, to try it out? Since we all know that things
which sound good on paper don't always work out that well in
practice.)
There's good news and bad news here. It has been 100% implemented, both
language and library (that's the good news), except that std::unique_ptr
is called Metrowerks::move_ptr. The bad news is that it is only
available on CodeWarrior Pro 10, Macintosh only, and I'm not even sure
Freescale is still selling it - they have exited that market. If you
have it, or can get your hands on it, it is not available by default.
You have to:
#pragma rvalue_refs on
preferably in a prefix file.
Russell Yanofsky reported that he implemented it in gcc 4.0 about a year
ago.
http://groups.google.com/group/comp.std.c++/browse_frm/thread/64bf775bdf0
69dad/3b905848b46253d5?lnk=st&q=rvalue+reference+group%3Acomp.std.c%2B%2B
&rnum=1&hl=en#3b905848b46253d5
Unfortunately his link is no longer working, and as far as I know, this
work never made it into gcc (I'd love to see it there).
Despite the restriction on copy semantics, unique_ptr will go
into std::containers (unlike) auto_ptr. This is because
std::containers will use move internally, instead of copy.
vector<unique_ptr<int>> v;
v.push_back(unique_ptr<int>(new int(1))); // ok, moved in
Such a container is movable, but not copyable. It's elements
can be moved in or out of the container, but not copied in or
out of the container.
I'm not sure of the implications here. Given v, above, what
does v[0] return? What happens if I move it? What is left at
v[0] in the container?
v[0] returns a unique_ptr<T>&. If you copy from it, you get a
compile-time error. If you move from it, a "null" default constructed
unique_ptr<T> is left in the vector at v[0]. Or you could move into it,
but not copy into it. Or you could reset it, swap it, etc.
Such containers of movable but non-copyable types will also be
able to be manipulated with many std::algorithms (which will
use swap/move instead of copy) such as sort, push/pop_heap,
partition, rotate, remove_if, etc. If an attempt is made to
use such a sequence with an algorithm that requires copy
semantics, a compile-time error will result.
Note that ownership transfer requires a non-const unique_ptr
source. If you want to prohibit ownership transfer from a
unique_ptr, (like scoped_ptr), make it const.
Which isn't always an option, e.g. if I want my pimpl to support
assignment.
This might look like:
struct impl;
class Pimpl
{
private:
std::unique_ptr<impl> p_;
public:
Pimpl();
// ...
Pimpl& operator=(const Pimpl& p);
};
int main()
{
Pimpl p1, p2;
p2 = p1;
}
// --firewall--
struct impl
{
int data_;
};
Pimpl::Pimpl()
: p_(new impl)
{
}
Pimpl&
Pimpl::operator=(const Pimpl& p)
{
if (this != &p)
*p_ = *p.p_;
return *this;
}
In the end, it sounds like a good replacement for auto_ptr. I
think I'd rather prefer to have a scoped_ptr along side of it,
if for no other reason that it seems clearer to have two
distinctly named types for two different target semantics.
Upon further investigation, boost::scoped_ptr isn't really guaranteeing
you a scoped lifetime either:
scoped_ptr<T> global;
void foo()
{
scoped_ptr<T> p(/*...*/);
// use *p
swap(p, global);
}
There are two fixes if you want to restrict this further:
const scoped_ptr<T> p(/*...*/);
or remove swap from scoped_ptr's repertoire.
Of course and then there's really bizarre use cases if we care to worry
about them:
scoped_ptr<T>* p = new scoped_ptr<T>(/*...*/)
// use **p
Such users probably deserve whatever they get. :-)
-Howard
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]