Which is preferable std::auto_ptr or boost's smart pointer?

[BekTek]

How do you think?
and why?

 

[Matthias =?ISO-8859-1?Q?K=E4ppler?=]

How do you think?
and why?

Boost has several different smart pointer types, each tailored for a
specific need, which allows for more flexibility. I would go with boost.
I have even heard that boost smart pointers are subject to enter the C++
standard library on the next revision.

- Matthias

 

[Howard Hinnant]

Boost has several different smart pointer types, each tailored for a
specific need, which allows for more flexibility. I would go with boost.
I have even heard that boost smart pointers are subject to enter the C++
standard library on the next revision.

- Matthias

Proposals based on boost::shared_ptr and boost::weak_ptr have been
accepted into the first library technical report (TR1). This does not
mean that they are standard, only that they are being seriously
considered for standardization. Other boost smart pointers (scoped_ptr,
shared_array, intrusive_ptr, etc.) have not been proposed.

As to the OP's original question, it is not answerable without some
context on what the smart pointer is supposed to do. I would not advise
using shared_ptr when auto_ptr is a better fit, nor vice-versa.

-Howard

 

[Jonathan Turkanis]

How do you think?
and why?

As others have mentioned, boost::shared_ptr and std::auto_ptr are useful in
different types of situations. If you decide that auto_ptr is more appropriate,
however, you might also consider this implementation of move_ptr (based in large
part on Howard's work):

http://home.comcast.net/~jturkanis/move_ptr/

(It is used as an implementation detail in the recently reviewed Boost Smart
Containers library, by Thorsten Ottosen, and may therefore soon become an
undocumented part of Boost.)

The library documentation gives a detailed analysis of the differences between
move_ptr and auto_ptr, as well as some useful references on auto_ptr.

Jonathan

 

[Cy Edmunds]

How do you think?
and why?

They both have their uses, so I wouldn't call one "better". However,
std::auto_ptr does have a characteristic which is hard to like: for
auto_ptr's x and y

y = x;

changes both x and y. This can certainly cause confusion in use. A similar
propery of auto_ptr's copy constructor makes in unusable in standard
containers such as std::vector. Also note that a class which contains an
auto_ptr as a member will have the same dubioius properties.

boost::shared_ptr has none of these issues.

 

[Jonathan Turkanis]

They both have their uses, so I wouldn't call one "better". However,
std::auto_ptr does have a characteristic which is hard to like: for
auto_ptr's x and y

y = x;

changes both x and y. This can certainly cause confusion in use.

This one of the main attractions of move_ptr: the above won't compile. If you
really want to transfer ownership from x to y, you have to write

y = move(x);

Jonathan

 

[Howard Hinnant]

This one of the main attractions of move_ptr: the above won't compile. If you
really want to transfer ownership from x to y, you have to write

y = move(x);

And kudos to Jonathan for implementing and making this available in
C++03 (as much as possible). I'm very much looking forward to the day
when this animal can be put into std::containers, and used with
std::algorithms.

-Howard

 

[Dietmar Kuehl]

This one of the main attractions of move_ptr: the above won't compile. If you
really want to transfer ownership from x to y, you have to write

y = move(x);

Apparently I have become seriously stupid but I don't see it:

| std::auto_ptr<int> x(new int(1));
| std::auto_ptr<int> y;
| y = x;

You seem to assert that the assignment in the above statement does not
compile. I can see that it may have unexpected behavior but not that it
does not compile. Can you please shed some light on this? Maybe you
were
refering to the situation where a function is returning an 'auto_ptr':

| std::auto_ptr<int> foo() { return std::auto_ptr<int>(new int(1)); }
| int main() {
| std::auto_ptr<int> x = foo(); // OK: there is a special ctor (*)
| x = foo(); // error: need non-const reference
| }

(*) At least, this is supposed to work. I seem to remember a discussion
which somehow deduced that this actually does not work. Is this
what you are refering to?

 

[Howard Hinnant]

Apparently I have become seriously stupid but I don't see it:

| std::auto_ptr<int> x(new int(1));
| std::auto_ptr<int> y;
| y = x;

You seem to assert that the assignment in the above statement does not
compile. I can see that it may have unexpected behavior but not that it
does not compile. Can you please shed some light on this? Maybe you
were
refering to the situation where a function is returning an 'auto_ptr':

| std::auto_ptr<int> foo() { return std::auto_ptr<int>(new int(1)); }
| int main() {
| std::auto_ptr<int> x = foo(); // OK: there is a special ctor (*)
| x = foo(); // error: need non-const reference
| }

Hi Dietmar,

What Jonathan meant was that if the type of the smart pointer is
move_ptr, instead of auto_ptr, then the assignment won't compile:

y = x; // compile time error

This is a safety feature of move_ptr, especially in generic code where
moving from lvalues with copy syntax can render the generic algorithm
incorrect.

-Howard

 

[Jonathan Turkanis]

"Dietmar Kuehl" <[email protected]> wrote:

Hi Dietmar,

What Jonathan meant was that if the type of the smart pointer is
move_ptr, instead of auto_ptr, then the assignment won't compile:

y = x; // compile time error

This is a safety feature of move_ptr, especially in generic code where
moving from lvalues with copy syntax can render the generic algorithm
incorrect.

Yes, that's what I was trying to say. Sorry I wan't clear.

-Howard

Jonathan