What is the advantage of Boost scoped_ptr?

[yinglcs]

I am reading the Boost scoped_ptr library, and I wonder what is the
advantage of using that.

Here is an example from Boost.org web site:

#include <boost/scoped_ptr.hpp>
#include <iostream>

struct Shoe { ~Shoe() { std::cout << "Buckle my shoe\n"; } };

class MyClass {
boost::scoped_ptr<int> ptr;
public:
MyClass() : ptr(new int) { *ptr = 0; }
int add_one() { return ++*ptr; }
};

int main()
{
boost::scoped_ptr<Shoe> x(new Shoe);
MyClass my_instance;
std::cout << my_instance.add_one() << '\n';
std::cout << my_instance.add_one() << '\n';
}

can't I simple change code to allocate the 'Shoe' object from the stack
instead of getting it from the heap, like this:
int main()
{
Shoe shoe;
MyClass my_instance;
std::cout << my_instance.add_one() << '\n';
std::cout << my_instance.add_one() << '\n';
}

since we don't pass scoped_ptr outside the function (that is the
functionality of Boost shared_ptr), I don't the advantage of using
Boost scoped_ptr.

Thank you.

 

[Thomas Tutone]

I am reading the Boost scoped_ptr library, and I wonder what is the
advantage of using that.

Think of it as a non-copyable, non-assignable std::auto_ptr - i.e., it
is exception safe, unlike a normal pointer.

From the Boost website:

"The scoped_ptr class template stores a pointer to a dynamically
allocated object. (Dynamically allocated objects are allocated with the
C++ new expression.) The object pointed to is guaranteed to be deleted,
either on destruction of the scoped_ptr, or via an explicit reset....
The scoped_ptr template is a simple solution for simple needs. It
supplies a basic "resource acquisition is initialization" facility,
without shared-ownership or transfer-of-ownership semantics. Both its
name and enforcement of semantics (by being noncopyable) signal its
intent to retain ownership solely within the current scope. Because it
is noncopyable, it is safer than shared_ptr or std::auto_ptr for
pointers which should not be copied."

Here is an example from Boost.org web site:

#include <boost/scoped_ptr.hpp>
#include <iostream>

struct Shoe { ~Shoe() { std::cout << "Buckle my shoe\n"; } };

class MyClass {
boost::scoped_ptr<int> ptr;
public:
MyClass() : ptr(new int) { *ptr = 0; }
int add_one() { return ++*ptr; }
};

int main()
{
boost::scoped_ptr<Shoe> x(new Shoe);
MyClass my_instance;
std::cout << my_instance.add_one() << '\n';
std::cout << my_instance.add_one() << '\n';
}

can't I simple change code to allocate the 'Shoe' object from the stack
instead of getting it from the heap, like this:
int main()
{
Shoe shoe;
MyClass my_instance;
std::cout << my_instance.add_one() << '\n';
std::cout << my_instance.add_one() << '\n';
}

since we don't pass scoped_ptr outside the function (that is the
functionality of Boost shared_ptr), I don't the advantage of using
Boost scoped_ptr.

In this particular instance, you may be right. But what if MyClass is
abstract?

Best regards,

Tom

 

[Roland Pibinger]

I am reading the Boost scoped_ptr library, and I wonder what is the
advantage of using that.

First let me clarify that I neither endorse 'smart' pointers nor
'Boost'.

Here is an example from Boost.org web site: [...]
int main()
{
boost::scoped_ptr<Shoe> x(new Shoe); [...]
}

can't I simple change code to allocate the 'Shoe' object from the stack
instead of getting it from the heap, like this:
int main()
{
Shoe shoe; [...]
}

since we don't pass scoped_ptr outside the function (that is the
functionality of Boost shared_ptr), I don't the advantage of using
Boost scoped_ptr.

Yes you can (and should) do it in that case. The main difference is
that a scoped_ptr can be 'empty' (point to 0) and can be re-set
without copying the pointed-to object (although .reset() works
differently compared to shared_ptr). scoped_ptr isn't safer than a
real pointer (when you dereference an 'empty' scoped_ptr your program
probably crashes).

Best wishes,
Roland Pibinger

 

[Joe Gottman]

I am reading the Boost scoped_ptr library, and I wonder what is the
advantage of using that.

First let me clarify that I neither endorse 'smart' pointers nor
'Boost'.

Here is an example from Boost.org web site: [...]
int main()
{
boost::scoped_ptr<Shoe> x(new Shoe); [...]
}

can't I simple change code to allocate the 'Shoe' object from the stack
instead of getting it from the heap, like this:
int main()
{
Shoe shoe; [...]
}

since we don't pass scoped_ptr outside the function (that is the
functionality of Boost shared_ptr), I don't the advantage of using
Boost scoped_ptr.

Yes you can (and should) do it in that case. The main difference is
that a scoped_ptr can be 'empty' (point to 0) and can be re-set
without copying the pointed-to object (although .reset() works
differently compared to shared_ptr). scoped_ptr isn't safer than a
real pointer (when you dereference an 'empty' scoped_ptr your program
probably crashes).

The key advantage of scoped_ptr over a real pointer is that it avoids
memory leaks when you leave the function early, either because of a throw or
because a maintenance programmer added an early return statement. If you do
need to create an object on the stack (because you require polymorphism for
example) then scoped_ptr is better than raw pointers.

Joe Gottman