Programming Forums > Application Development > C++

Game_Ender · Apr 6th, 2007, 9:36 PM

Well the scope block was just an example to show how explicity how that auto_ptr manages memory. auto_ptr is actually perfect for use in a complex program, just not always with scope blocks like that. It allows you to create temporary heap objects and not have to explicitly delete them, even in the presence of exceptions. Let this example illustrate:

 cpp Syntax (Toggle Plain Text) 
void my_func(int* size, int param1, double param2)
{
    std::auto_ptr<A> temp_obj(new A(param1));
 
    some_func_which_throws(temp_obj.get());
 
    // lots of code ...
 
    another_func_which_throws(param2, temp_obj.get());
 
    // lots of code ...
 
    // temp_obj deleted, even if those function throw an exception.
    // Stack objects are destructed as the exception rolls back the stack.
}
void my_func(int* size, int param1, double param2)
{
    std::auto_ptr<A> temp_obj(new A(param1));

    some_func_which_throws(temp_obj.get());

    // lots of code ...

    another_func_which_throws(param2, temp_obj.get());

    // lots of code ...

    // temp_obj deleted, even if those function throw an exception.
    // Stack objects are destructed as the exception rolls back the stack.
}

Seif · Apr 6th, 2007, 10:56 PM

I thought auto_ptr should never be used in STL containers due to ownership transfer issues when assigning one pointer to another.

Jimbo · Apr 7th, 2007, 12:39 AM

Having never used auto_ptr in an actual program, I'm finding myself very unimpressed with it. The issue shown in the code I posted above, plus the thought of what might happen in a multi-threaded app, seem to make the use of auto_ptr extremely prone to errors if a developer isn't careful and thorough. I'm curious as to grumpy's opinion on it's use though, as he's probably seen it more than the rest of us (and he provides a more experienced perspective).

grumpy · Apr 7th, 2007, 3:53 AM

Quote:

Originally Posted by Jimbo

Having never used auto_ptr in an actual program, I'm finding myself very unimpressed with it.

It's like all these things; auto_ptr is designed to be used in a particular way, and using it in other ways doesn't tend to be a way to get good results.

auto_ptr is designed with a very precise purpose in mind. It meets that purpose beautifully. The biggest problem with it, however, is that programmers try to do more with it than it is designed for -- such as using it as a poor-mans garbage collector, or putting it into containers.

Quote:

Originally Posted by Jimbo

The issue shown in the code I posted above, plus the thought of what might happen in a multi-threaded app, seem to make the use of auto_ptr extremely prone to errors if a developer isn't careful and thorough.

Apart from proposals that are under discussion for a future version of the standard, the whole C++ standard has no mention of multi-threading. It's hardly surprising that use of auto_ptr or anything else will pose challenges in a multi-threaded program if you care about correctness.

In practice, as long as the auto_ptr and the object it manages are only accessed by one thread, then auto_ptr can be used as intended. If it is shared by multiple threads, then it is necessary to protect access to the complete auto_ptr object (eg using critical sections or mutexes). That is equally true of any standard container (vector, list, etc) though. One reason why multi-threaded programs have to protect objects that are shared between threads is that objects can't generally protect themselves (i.e. behave correctly) if they are accessed from multiple threads.

Quote:

Originally Posted by Jimbo

I'm curious as to grumpy's opinion on it's use though, as he's probably seen it more than the rest of us (and he provides a more experienced perspective).

auto_ptr<> is not intended as a poor-mans garbage collector, and shouldn't really be used as such a thing. It is designed to link the lifetime of a single dynamically allocated object to the lifetime of a stack object.

Your little code example, which I recreate here, exhibits that;

(Toggle Plain Text)

int main()
{
     B* raw_ptr = new B(1);
    {
      std::auto_ptr<B> managed(raw_ptr);
      managed->a->val = 24;
      std::cout << managed->a->val << std::endl;
      std::cout << raw_ptr->a->val << std::endl;
    }
    // auto_ptr now out of scope and object is deleted

    std::cout << raw_ptr->a->val << std::endl;
    return 0;
}

The problem with this code is that the last line, which dereferences raw_ptr, yields undefined behaviour, because the preceding code has made raw_ptr become a dangling pointer (it's value is the address of an object which no longer exists). The destructor for that object would have been invoked at the end of the enclosed block (the auto_ptr<> destructor would have effectively deleted raw_ptr).

There are a few other limitations of auto_ptr as well. One of those is that the assignment of an auto_ptr modifies both operands (i.e. "a = b;" where a and b are both auto_ptr objects, modifies both a and b). The reason for this is that assignment of auto_ptr effectively hands off control of the object being managed: a's object must be released, so that a can take over management of the object from b, and b will subsequently manage no object. This is not the sort of behaviour a standard container (vector, list, etc) expects of the objects it contains -- which is one reason why a vector of auto_ptr's is invalid.

If you want to do things for which auto_ptr is not designed (eg place multiple managed pointers into a standard container) then auto_ptr is not the right tool. The Boost library provides a range of other "smart pointer" types that are better suited to such tasks. Each of those smart pointer types has different pros and cons, because they are designed for different use cases. The main practical problem with libraries like Boost is selecting the right smart pointer: each, like auto_ptr, is designed for a particular usage pattern and will not give desired results if used in other ways.

Incidentally, Jimbo, the destructor for your type B needs to delete the contained A to avoid a memory leak.

rwm · Apr 10th, 2007, 5:23 AM

interesting...

Apr 6th, 2007, 9:36 PM	#11
Game_Ender Professional Programmer Join Date: May 2006 Location: Maryland, USA Posts: 306 Rep Power: 3	Well the scope block was just an example to show how explicity how that auto_ptr manages memory. auto_ptr is actually perfect for use in a complex program, just not always with scope blocks like that. It allows you to create temporary heap objects and not have to explicitly delete them, even in the presence of exceptions. Let this example illustrate: cpp Syntax (Toggle Plain Text) void my_func(int* size, int param1, double param2) { std::auto_ptr<A> temp_obj(new A(param1)); some_func_which_throws(temp_obj.get()); // lots of code ... another_func_which_throws(param2, temp_obj.get()); // lots of code ... // temp_obj deleted, even if those function throw an exception. // Stack objects are destructed as the exception rolls back the stack. } void my_func(int* size, int param1, double param2) { std::auto_ptr<A> temp_obj(new A(param1)); some_func_which_throws(temp_obj.get()); // lots of code ... another_func_which_throws(param2, temp_obj.get()); // lots of code ... // temp_obj deleted, even if those function throw an exception. // Stack objects are destructed as the exception rolls back the stack. } __________________ Robotics @ Maryland AUV Team - Software Lead

Apr 7th, 2007, 12:39 AM	#13
Jimbo Battle Programmer Join Date: Feb 2006 Location: Bellevue, WA, USA Posts: 763 Rep Power: 3	Having never used auto_ptr in an actual program, I'm finding myself very unimpressed with it. The issue shown in the code I posted above, plus the thought of what might happen in a multi-threaded app, seem to make the use of auto_ptr extremely prone to errors if a developer isn't careful and thorough. I'm curious as to grumpy's opinion on it's use though, as he's probably seen it more than the rest of us (and he provides a more experienced perspective). __________________ <insert disclaimer here> <insert shameless plug for Visual Studio here>

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Apr 6th, 2007, 10:56 PM	#12
Seif Hobbyist Programmer Join Date: Jan 2006 Location: UK Posts: 215 Rep Power: 3	I thought auto_ptr should never be used in STL containers due to ownership transfer issues when assigning one pointer to another.

Apr 10th, 2007, 5:23 AM	#15
rwm Professional Programmer Join Date: Jan 2007 Location: Cape Town Posts: 291 Rep Power: 2	interesting...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Programming Forums > Application Development > C++

STL and memory management