auto_ptr versus shared_ptr

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • auto_ptr versus shared_ptr

      Hi,

      What is the differances between "auto_prt" and
      "shared_ptr"? My understanding is that they are
      pretty much the same as far as managing memory,
      and avoiding the memory leaking issues, right?

      Also, could you provide some references (web sites)
      explanation and simple examples of both, please?


      Thank you again,

      Sabrina.
    • I just realized that I don't really know auto_ptr that well.

      I do know that auto_ptr is a part of STL and shared_ptr is a part of boost.

      I found this to be a good crash course on auto_ptr for me:
      gotw.ca/publications/using_auto_ptr_effectively.htm
      of particular note in that article was the following:
      For auto_ptr, copies are NOT equivalent.
      That means that unlike boost::shared_ptr, you cannot just pass that pointer around and share the pointer among various owners. std::auto_ptr is basically just a means of automatically calling delete on the object when it goes out of scope.

      In contrast, boost::shared_ptr not only calls delete on the object when it goes out of scope, but it also manages reference counts to the object so you can copy that shared_ptr around and assign it to make duplicates of the shared_ptr so that every instance of that shared_ptr references the very same object, and that object is guranteed to exist until all the shared_ptr's referring to that object are either out of scope or resetted.

      So if I understand correctly, the std::auto_ptr is completely redundant with boost::scoped_ptr. You can find the description of boost::scoped_ptr here:
      boost.org/libs/smart_ptr/scoped_ptr.htm
      This following quote about scoped_ptr is especially telling:
      Because it is noncopyable, it is safer than shared_ptr or std::auto_ptr for pointers which should not be copied.
      I find it very dangerous on the part of the STL crew to allow copy and assignment on an auto_ptr when it will only lead to disaster. boost::scoped_ptr has the right idea by not allowing this (making operator= and copy constructor private within the scoped_ptr template class).

      boost::shared_ptr is described here:
      boost.org/libs/smart_ptr/shared_ptr.htm

      So why would you ever want to use scoped_ptr over shared_ptr? I'm not entirely sure. The only thing I can think of is because scoped_ptr uses less resources and probably has less performance overhead, maybe.
    • RE: auto_ptr versus shared_ptr

      I'm not sold on them either, but that might be because I haven't written a program expected to run longer than a few minutes. I DO know that I have a habit of forgetting to clean up my 'new's with the 'delete's, so maybe a smart pointer isn't a horrible idea.

      The point is that the performance loss of using a class should be an investment to protect against memory leaks (which can be quite bad in programs that run a while, like games).
      -Larrik Jaerico

      www.LarrikJ.com
    • Larrik has the right idea... it is an investment. Especially when you are writing very large programs with more than one programmer.

      To put this into perspective, I've been told by an ex-Retro employee that Metroid Prime and its sequel make heavy use of smart pointers, factories, and other template classes whose sole purpose is to enforce (at compile time) a strong structure in the codebase so that even the most absent-minded programmer will be unlikely to induce memory leaks. This ex-Retro employee is also the same person who dragged me kicking and screaming into his world of design patterns and smart pointers. I, too, did not see the point of using these extra overhead templates to complicate my code all for the sake of not trusting myself... because I trust myself. It took me a long time to be convinced that this was a good thing. I guess the zero memory leaks and only one known bug on the project he was working on at the code complete milestone was convincing enough.

      Smart pointers will be overkill for very small apps written by one person, and they are definitely not appropriate for systems that can't spare the CPU cycles, but there is definitely a place for these in modern game development.

      You are right about there being overhead, specifically, one 32-bit void* per smart pointer instance and one integer refcount per block of memory managed by those instances. There is also performance overhead of abstracting memory instead of direct access. Performance will be lost using smart pointers instead of raw pointers, just like performance will be lost using C/C++ instead of assembly or scripting languages instead of hard-coded functionality. You're sacrificing performance for productivity by choosing this style.

      Here's an exercise for ya: Try implementing that queing event system in volume 2 of Game Code Complete without the use of boost::shared_ptr while still maintaining a leakproof architecture. It is possible but is it worth it for the system that you are targeting?

      The post was edited 1 time, last by Kain ().

    • RE: auto_ptr versus shared_ptr

      If you can see it more in the light of economics (investment/return, etc), it'll help a little better. Remember, saving every CPU cycle isn't always the best way.

      There are three basic commoditiies of programmer:
      1) Execution time
      2) Memory space
      3) Programmer time (e.g. writing time)

      That is the order I remember seeing that list (if in fact I've seen it before), but the list is still misleading. For one, it's assuming that your program has NO bugs before you can start applying this balance. For two, in practical terms #3 is usually the most important (by far), and the other may or may not be important based on your application. Sur eyou don't want to bloat the memory, but shared pointers are not going to even noticeably impact it. After all, one leaked .BMP can probably cost you more in memory than all of your shared pointers combined.

      Ah, the turmoil of programming...
      -Larrik Jaerico

      www.LarrikJ.com
    • RE: auto_ptr versus shared_ptr

      Hi,

      Well, I didnt want to stir up a hornets nest with this
      subject, but thanks again for the reply. I was reading
      the book and the author mentioned the use of
      'shared_prt'. I would like to ask if anyone would like to
      povide another example(s) of how to use them. I am still
      unclear on this subject.

      Thank you.

      Sabrina
    • Originally posted by Larrik
      You guys gotta hit the little reply button at the top of the post instead of the big one at the bottom. Or Mr.Mike needs to sift through the PHP and change/remove the bottom one.
      You gotta stop using "Tree Structure" :D

      Profile/Edit Options/Threads Structure Display = Board Structure

      ^ That makes things much easier.
    • RE: auto_ptr versus shared_ptr

      Originally posted by Larrik
      ...but the list is still misleading. For one, it's assuming that your program has NO bugs before you can start applying this balance. For two, in practical terms #3 is usually the most important (by far), and the other may or may not be important based on your application.


      Yeah your right, optimisations should generally be the last step. It's better to get the program working fully and bug free than running fast but incomplete and buggy. Once you have the final product you could always then start replacing the smart pointers with regular ones, which would be a lot easier than trying to deal with memory leaks during the development process.

      The post was edited 1 time, last by Gerry ().