Smart Pointer Question.

[Amish79]

When is it advantageous to use smart pointer? &
When it is disadvantageous to use smart pointers?

It would be good if you can provide me with an example which can explain me both the above suitations.

I appreciate your effort.

Thanks in advance,
Amish.

[RoboTact]

Smart pointer can delete object, pointer to which it contains, you don't need to write delete code in destructor every time you add an object by pointer to your class definition (if that class owns that object) and you don't need to check if the object can be deleted and when it should be deleted if this object is not owned by any class. You can pass "copy" of class with some kind of smart pointer (I don't know it it still can be named "smart pointer"), creating another smart pointer as a copy, ang getting read only access to the same object and octually copying it when change is required ("delayed copy", like unix fork, CString in MFC). You can implement all this object managment control, that's it.

[Hediea]

When is it advantageous to use smart pointer? &
When it is disadvantageous to use smart pointers?

It would be good if you can provide me with an example which can explain me both the above suitations.

I appreciate your effort.

Thanks in advance,
Amish.

I tried o search the net for yuo an example, didn't know how it should work cause i am also slow in programming.

 class sp
  {
       public:
           int del;
           sp* operator ->() { return this;};
  };

  int main()
  {
       sp t;
       cout << t->del;
  }

[wien]

I tried o search the net for yuo an example, didn't know how it should work cause i am also slow in programming.

That's no smart-pointer. In fact, I'm not sure what that is supposed to be. Looks like an example of operator -> overloading.

Anyhoo... A smart pointer (like for instance std::auto_ptr or boost::shared_ptr) can for example be of great help when using dynamically allocated memory, while keeping the code exception safe. Consider the following example:

try
    {
    int* ptr = new int;
    throw 0;
    }
catch(int ex)
    {}

Here the pointer to the memory allocated by new will be lost, and you have a memory leak. By using a smart pointer instead, the deallocation will be handeled automatically, and no memory leaks occur. Like so:

try
    {
    std::auto_ptr<int> ptr = new int;
    throw 0;
    }
catch(int ex)
    {}

Reference counted smart pointers like boost::shared_ptr, can also be useful when multiple objects need to have a reference to the same object, and the destruction order of these objects is not obvious.

But even though they seem cool and the temptation to "go Java" (Use new all over the place, in combination with smart pointers) is great, you should be absolutely sure that a smart pointer, or more specifically dynamically allocated memory, is really what you need before you use them. Only use dynamically allocated memory if you have a really compelling reason to do so. Otherwise make do with the stack, and the standard containers.

[Andreas Masur]

try
    {
    std::auto_ptr<int> ptr = new int;
    throw 0;
    }
catch(int ex)
    {}

Well...it will rather be

try
    {
    std::auto_ptr<int> ptr(new int);
    throw 0;
    }
catch(int ex)
    {}

The standard smart pointer does not allow initialization with an ordinary pointer using assignment.

[wien]

Woops.. Right you are sir!

[marten_range]

The purpose of almost all smart pointers are to help manage object lifetimes.

Common smart pointers are:

std::auto_ptr
CComPtr
CComQIPtr
_com_ptr_t
boost::shared_ptr
boost::intrusive_ptr
boost::scoped_ptr
Loki::SmartPtr

And the list goes on.

They are same but different so to say. They are all same in the way that they all try to help you manage object lifetimes but they are different in that they fit for different situations.

Loki::SmartPtr is the one-size-fits-all attempt by Andrei Alexandrescu.

Although implicitly given by what wien said I thought I just point out that it's not only in the presence of exceptions that you can get problem with memory leaks when not using smart pointers.

Consider:

void f( int const action )
{
    int * l_ptr(new int(3));

    if( action == 0 )
    {
        return;    // memory leak
    }
    else if( action == 1 )
    {
        throw std::runtime_error("error");    // memory leak
    }
    else if( action == 2 )
    {
        l_ptr = new int(4); // memory leak
    }

    delete l_ptr;
}

Of course, when you write the code you know how it's supposed to be used but then the maintenance programmer comes in and he/she has to apply a quick fix. He/she might then not be aware on how the life-time in your application is handled and might introduce memory leaks.

One might think that using single point of return plus try...catch is enough to deal with memory management without smart pointer but exceptions can occur in the darnest of players (consider http://www.gotw.ca/gotw/020.htm) and it can be quite easy to miss a place.

By using a smart pointer it guarantees that the pointee destructor will be called when the smart pointer goes out of scope.

So smart pointers helps with object lifetimes. That's all well and good.

The problem of many smart pointers implementations is that they desperatly try to look as a ordinary plain pointers which can be confusing because a smart pointer is _not_ a plain pointer. Common mistake by smart pointer implementations is that they overload operator & to mimic the plain pointer (CComPtr and CComQIPtr has been notorius for this). But this also makes these smart pointers incompatible with standard containers (which requires a operator & to behave like it defined in the standard). Also many smart pointers (again CComPtr and CComQIPtr) allows implicit conversion to the pointee type which has created many memory leaks over the years. It's all well intended but the road to heck is paved with good intentions.

Also when using smart pointers the pointee class destructor must _not_ throw exceptions. This is very important!

Consider this:

struct x
{
    ~x()
    {
        throw std::runtime_error("error");
    }
};

void f()
{
    std::auto_ptr<x> const l_ptr(new x());
    throw std::runime_error("error"); // here exit(0) will be called
}

So at the second throw the whole program terminates. This is according to the standard (to be honest I don't have the standard before so I don't know if this is a hard fact). This is because when reaching the second throw an exception is placed on the "stack" (not sure of the exact wording here). std::auto_ptr goes out of scope and ~x() is called. Then a new exception is thrown but there is already one "active". This is illegal and the c++ runtime shall terminate the app.

Can be suprising and hard to find.


So drawback of smart pointers are:
1. They are not plain pointers even if many smart pointers tries very hard to look like one.
2. The destructor of the pointee type must not throw.
3. Some smart pointers are incompatible with the standard containers (but then the plain pointers never really were compatible either)


There are more but I'm just not smart enough right now to think of more and the post is long enough already.

The big question is then:

Is it worth it to use smart pointers.

And my answer is:
Yes!

Always, always use smart pointers. Get used to using smart pointers and scope guards. Feel comfortable with smart pointers and use smart pointers of good quality such as boost::shared_ptr (and the rest of the boost smart pointers) or Loki::SmartPtr.

Hope this helps

PS. Lot of warning have been made around std::auto_ptr and it's correct that you should understand what std::auto_ptr is intended for but std::auto_ptr is one of the best smart pointers ever made. Sometimes it's _exactly_ what you want. The problem with std::auto_ptr is that it's shipped with STL but it can't be used in the standard containers => confusing.

[wien]

Also when using smart pointers the pointee class destructor must _not_ throw exceptions. This is very important!

This is in fact something that is good to keep as a rule of thumb all the time. You can get yourself into the same kind of mess even if you don't use smart pointers:

struct x
{
    ~x()
    {
        throw std::runtime_error("error");
    }
};

void f()
{
    x an_x;
    throw std::runime_error("error"); // just as bad...
}

[Graham]

In fact, go one further: no destructor should ever be allowed to throw an exception. Destructors that throw are evil and are the cause of buggy programs, system crashes and chicken pox. ( )

[KevinHall]

Doesn't the C++ standard state that exceptions can't be thrown from destructors?

[Andreas Masur]

Doesn't the C++ standard state that exceptions can't be thrown from destructors?

No...not really...it says in 15.3.2:

[Note: If a destructor called during stack unwinding exits with an exception, terminate is called (15.5.1). So destructors should generally catch exceptions and not let them propagate out of the destructor. —end note]

IIRC correctly the standard does not say explicitly that destructors aren't allowed to throw in the common sense...

[KevinHall]

I'll interpret that as:

One should not allow exceptions to escape a destructor or else terminate will be called.

That's a pretty strong discouragement there!

[Andreas Masur]

[QUOTE=KevinHall]I'll interpret that as:

[QUOTE]One should not allow exceptions to escape a destructor or else terminate will be called.

That's a pretty strong discouragement there!

Well...I do not disagree....destructors actually should not throw anything...however, it is not completely prohibited by the standard (or at least I did not find it yet)...

[KevinHall]

Even though the standard doesn't explicitly say one should not allow exceptions to be thrown from destructors, that's how people should interpret the standard. Calling terminate does indicate that your program won't continue working as otherwise expected!

Let's face the facts, when writing a destructor, people don't usually wrap the entire thing in a try/catch statement. I know I only do it when I think an exception is possible -- and that's on a good day when I remember to think about such things. So I believe the standardization comittee did the right thing here. They provided a controlled way to handle something people should not allow to happen (but that people will too often inadvertently allow to happen), rather than saying the behavior is undefined.

[Apollyon]

What an instrusive_ptr? What do all the other smart_ptrs do? And who would name their namespaces "boost" and "Loki"?