--- /dev/null
+<?xml version="1.0" encoding="UTF-8" standalone="no"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>auto_ptr</title><meta name="generator" content="DocBook XSL Stylesheets V1.74.0" /><meta name="keywords" content=" ISO C++ , auto_ptr " /><meta name="keywords" content=" ISO C++ , library " /><link rel="home" href="../spine.html" title="The GNU C++ Library Documentation" /><link rel="up" href="memory.html" title="Chapter 11. Memory" /><link rel="prev" href="memory.html" title="Chapter 11. Memory" /><link rel="next" href="shared_ptr.html" title="shared_ptr" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">auto_ptr</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="memory.html">Prev</a> </td><th width="60%" align="center">Chapter 11. Memory</th><td width="20%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr></table><hr /></div><div class="sect1" lang="en" xml:lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="manual.util.memory.auto_ptr"></a>auto_ptr</h2></div></div></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.limitations"></a>Limitations</h3></div></div></div><p>Explaining all of the fun and delicious things that can
+ happen with misuse of the <code class="classname">auto_ptr</code> class
+ template (called <acronym class="acronym">AP</acronym> here) would take some
+ time. Suffice it to say that the use of <acronym class="acronym">AP</acronym>
+ safely in the presence of copying has some subtleties.
+ </p><p>
+ The AP class is a really
+ nifty idea for a smart pointer, but it is one of the dumbest of
+ all the smart pointers -- and that's fine.
+ </p><p>
+ AP is not meant to be a supersmart solution to all resource
+ leaks everywhere. Neither is it meant to be an effective form
+ of garbage collection (although it can help, a little bit).
+ And it can <span class="emphasis"><em>not</em></span>be used for arrays!
+ </p><p>
+ <acronym class="acronym">AP</acronym> is meant to prevent nasty leaks in the
+ presence of exceptions. That's <span class="emphasis"><em>all</em></span>. This
+ code is AP-friendly:
+ </p><pre class="programlisting">
+ // Not a recommend naming scheme, but good for web-based FAQs.
+ typedef std::auto_ptr<MyClass> APMC;
+
+ extern function_taking_MyClass_pointer (MyClass*);
+ extern some_throwable_function ();
+
+ void func (int data)
+ {
+ APMC ap (new MyClass(data));
+
+ some_throwable_function(); // this will throw an exception
+
+ function_taking_MyClass_pointer (ap.get());
+ }
+ </pre><p>When an exception gets thrown, the instance of MyClass that's
+ been created on the heap will be <code class="function">delete</code>'d as the stack is
+ unwound past <code class="function">func()</code>.
+ </p><p>Changing that code as follows is not <acronym class="acronym">AP</acronym>-friendly:
+ </p><pre class="programlisting">
+ APMC ap (new MyClass[22]);
+ </pre><p>You will get the same problems as you would without the use
+ of <acronym class="acronym">AP</acronym>:
+ </p><pre class="programlisting">
+ char* array = new char[10]; // array new...
+ ...
+ delete array; // ...but single-object delete
+ </pre><p>
+ AP cannot tell whether the pointer you've passed at creation points
+ to one or many things. If it points to many things, you are about
+ to die. AP is trivial to write, however, so you could write your
+ own <code class="code">auto_array_ptr</code> for that situation (in fact, this has
+ been done many times; check the mailing lists, Usenet, Boost, etc).
+ </p></div><div class="sect2" lang="en" xml:lang="en"><div class="titlepage"><div><div><h3 class="title"><a id="auto_ptr.using"></a>Use in Containers</h3></div></div></div><p>
+ </p><p>All of the <a class="ulink" href="../23_containers/howto.html" target="_top">containers</a>
+ described in the standard library require their contained types
+ to have, among other things, a copy constructor like this:
+ </p><pre class="programlisting">
+ struct My_Type
+ {
+ My_Type (My_Type const&);
+ };
+ </pre><p>
+ Note the const keyword; the object being copied shouldn't change.
+ The template class <code class="code">auto_ptr</code> (called AP here) does not
+ meet this requirement. Creating a new AP by copying an existing
+ one transfers ownership of the pointed-to object, which means that
+ the AP being copied must change, which in turn means that the
+ copy ctors of AP do not take const objects.
+ </p><p>
+ The resulting rule is simple: <span class="emphasis"><em>Never ever use a
+ container of auto_ptr objects</em></span>. The standard says that
+ “<span class="quote">undefined</span>” behavior is the result, but it is
+ guaranteed to be messy.
+ </p><p>
+ To prevent you from doing this to yourself, the
+ <a class="ulink" href="../19_diagnostics/howto.html#3" target="_top">concept checks</a> built
+ in to this implementation will issue an error if you try to
+ compile code like this:
+ </p><pre class="programlisting">
+ #include <vector>
+ #include <memory>
+
+ void f()
+ {
+ std::vector< std::auto_ptr<int> > vec_ap_int;
+ }
+ </pre><p>
+Should you try this with the checks enabled, you will see an error.
+ </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="memory.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="memory.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="shared_ptr.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 11. Memory </td><td width="20%" align="center"><a accesskey="h" href="../spine.html">Home</a></td><td width="40%" align="right" valign="top"> shared_ptr</td></tr></table></div></body></html>
projects / msp430-gcc.git / blobdiff