[ceph.git] / ceph / src / boost / libs / smart_ptr / smart_ptr.htm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
    <head>
        <title>Smart Pointers</title>
        <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
    </head>
    <body text="#000000" bgcolor="#ffffff" link="#0000ff" vlink="#0000ff">
        <h1><img height="86" alt="boost.png (6897 bytes)" src="../../boost.png" 
            width="277" align="middle" border="0">Smart Pointers</h1>
        <p><a href="#Introduction">Introduction</a><br>
            <a href="#common_requirements">Common Requirements</a><br>
            <a href="#Exception_Safety">Exception Safety</a><br>
            <a href="#Exception-specifications">Exception-specifications</a><br>
            <a href="#History">History and Acknowledgements</a><br>
            <a href="#References">References</a></p>
        <h2><a name="Introduction">Introduction</a></h2>
        <p>Smart pointers are objects which store pointers to dynamically allocated (heap)
            objects. They behave much like built-in C++ pointers except that they
            automatically delete the object pointed to at the appropriate time. Smart
            pointers are particularly useful in the face of exceptions as they ensure
            proper destruction of dynamically allocated objects. They can also be used to
            keep track of dynamically allocated objects shared by multiple owners.</p>
        <p>Conceptually, smart pointers are seen as owning the object pointed to, and thus
            responsible for deletion of the object when it is no longer needed.</p>
        <p>The smart pointer library provides six smart pointer class templates:</p>
        <div align="left">
            <table border="1" cellpadding="4" cellspacing="0">
                <tr>
                    <td><a href="scoped_ptr.htm"><b>scoped_ptr</b></a></td>
                    <td><a href="../../boost/scoped_ptr.hpp">&lt;boost/scoped_ptr.hpp&gt;</a></td>
                    <td>Simple sole ownership of single objects. Noncopyable.</td>
                </tr>
                <tr>
                    <td><a href="scoped_array.htm"><b>scoped_array</b></a></td>
                    <td><a href="../../boost/scoped_array.hpp">&lt;boost/scoped_array.hpp&gt;</a></td>
                    <td>Simple sole ownership of arrays. Noncopyable.</td>
                </tr>
                <tr>
                    <td><a href="shared_ptr.htm"><b>shared_ptr</b></a></td>
                    <td><a href="../../boost/shared_ptr.hpp">&lt;boost/shared_ptr.hpp&gt;</a></td>
                    <td>Object ownership shared among multiple pointers.</td>
                </tr>
                <tr>
                    <td><a href="shared_array.htm"><b>shared_array</b></a></td>
                    <td><a href="../../boost/shared_array.hpp">&lt;boost/shared_array.hpp&gt;</a></td>
                    <td>Array ownership shared among multiple pointers.</td>
                </tr>
                <tr>
                    <td><a href="weak_ptr.htm"><b>weak_ptr</b></a></td>
                    <td><a href="../../boost/weak_ptr.hpp">&lt;boost/weak_ptr.hpp&gt;</a></td>
                    <td>Non-owning observers of an object owned by <b>shared_ptr</b>.</td>
                </tr>
                <tr>
                    <td><a href="intrusive_ptr.html"><b>intrusive_ptr</b></a></td>
                    <td><a href="../../boost/intrusive_ptr.hpp">&lt;boost/intrusive_ptr.hpp&gt;</a></td>
                    <td>Shared ownership of objects with an embedded reference count.</td>
                </tr>
            </table>
        </div>
        <p>These templates are designed to complement the <b>std::auto_ptr</b> template.</p>
        <p>They are examples of the "resource acquisition is initialization" idiom
            described in Bjarne Stroustrup's "The C++ Programming Language", 3rd edition,
            Section 14.4, Resource Management.</p>
        <p>Additionally, the smart pointer library provides efficient factory functions
            for creating smart pointer objects:</p>
        <div align="left">
            <table border="1" cellpadding="4" cellspacing="0">
                <tr>
                    <td><a href="make_shared.html"><b>make_shared, allocate_shared</b></a> for objects</td>
                    <td><a href="../../boost/make_shared.hpp">&lt;boost/make_shared.hpp&gt;</a></td>
                    <td>Efficient creation of <code>shared_ptr</code> objects.</td>
                </tr>
                <tr>
                    <td><a href="make_shared_array.html"><b>make_shared, allocate_shared</b></a> for arrays</td>
                    <td><a href="../../boost/make_shared.hpp">&lt;boost/make_shared.hpp&gt;</a></td>
                    <td>Efficient creation of <code>shared_ptr</code> arrays.</td>
                </tr>
                <tr>
                    <td><a href="make_unique.html"><b>make_unique</b></a></td>
                    <td><a href="../../boost/make_unique.hpp">&lt;boost/make_unique.hpp&gt;</a></td>
                    <td>Creation of <code>unique_ptr</code> objects and arrays.</td>
                </tr>
            </table>
        </div>
        <p>A test program, <a href="test/smart_ptr_test.cpp">smart_ptr_test.cpp</a>, is
            provided to verify correct operation.</p>
        <p>A page on <a href="compatibility.htm">compatibility</a> with older versions of
            the Boost smart pointer library describes some of the changes since earlier
            versions of the smart pointer implementation.</p>
        <p>A page on <a href="smarttests.htm">smart pointer timings</a> will be of interest
            to those curious about performance issues.</p>
        <P>A page on <A href="sp_techniques.html">smart pointer programming techniques</A> lists
            some advanced applications of <code>shared_ptr</code> and <code>weak_ptr</code>.</P>
        <h2><a name="common_requirements">Common Requirements</a></h2>
        <p>These smart pointer class templates have a template parameter, <b>T</b>, which
            specifies the type of the object pointed to by the smart pointer. The behavior
            of the smart pointer templates is undefined if the destructor or <b>operator delete</b>
            for objects of type <b>T</b> throw exceptions.</p>
        <p><b>T</b> may be an incomplete type at the point of smart pointer declaration.
            Unless otherwise specified, it is required that <b>T</b> be a complete type at
            points of smart pointer instantiation. Implementations are required to diagnose
            (treat as an error) all violations of this requirement, including deletion of
            an incomplete type. See the description of the <a href="../utility/utility.htm#checked_delete">
            <b>checked_delete</b></a> function template.</p>
        <P>Note that <STRONG>shared_ptr</STRONG> does not have this restriction, as most of
            its member functions do not require <STRONG>T</STRONG> to be a complete type.</P>
        <h3>Rationale</h3>
        <p>The requirements on <b>T</b> are carefully crafted to maximize safety yet allow
            handle-body (also called pimpl) and similar idioms. In these idioms a smart
            pointer may appear in translation units where <b>T</b> is an incomplete type.
            This separates interface from implementation and hides implementation from
            translation units which merely use the interface. Examples described in the
            documentation for specific smart pointers illustrate use of smart pointers in
            these idioms.</p>
        <p>Note that <b>scoped_ptr</b> requires that <b>T</b> be a complete type at
            destruction time, but <b>shared_ptr</b> does not.</p>
        <h2><a name="Exception_Safety">Exception Safety</a></h2>
        <p>Several functions in these smart pointer classes are specified as having "no
            effect" or "no effect except such-and-such" if an exception is thrown. This
            means that when an exception is thrown by an object of one of these classes,
            the entire program state remains the same as it was prior to the function call
            which resulted in the exception being thrown. This amounts to a guarantee that
            there are no detectable side effects. Other functions never throw exceptions.
            The only exception ever thrown by functions which do throw (assuming <b>T</b> meets
            the <a href="#common_requirements">common requirements</a>) is <b>std::bad_alloc</b>,
            and that is thrown only by functions which are explicitly documented as
            possibly throwing <b>std::bad_alloc</b>.</p>
        <h2><a name="Exception-specifications">Exception-specifications</a></h2>
        <p>Exception-specifications are not used; see <a href="http://www.boost.org/more/lib_guide.htm#Exception-specification">
            exception-specification rationale</a>.</p>
        <p>All the smart pointer templates contain member functions which can never throw
            exceptions, because they neither throw exceptions themselves nor call other
            functions which may throw exceptions. These members are indicated by a comment: <code>
            // never throws</code>.
        </p>
        <p>Functions which destroy objects of the pointed to type are prohibited from
            throwing exceptions by the <a href="#common_requirements">common requirements</a>.</p>
        <h2><a name="History">History</a> and Acknowledgements</h2>
        <p>February 2014. Glen Fernandes updated overloads of <b>make_shared</b> and 
            <b>allocate_shared</b> to conform to the specification in C++ standard paper 
            <a href="#D&amp;F-14">[D&amp;F-14]</a>, and implemented <b>make_unique</b> for 
            arrays and objects. Peter Dimov and Glen Fernandes updated the scalar and 
            array implementations, respectively, to resolve C++ standard library defect 
            2070.</p>
        <p>November 2012. Glen Fernandes provided implementations of <b>make_shared</b> 
            and <b>allocate_shared</b> for arrays. They achieve a single allocation for an
            array that can be initialized with constructor arguments or initializer lists 
            as well as overloads for default initialization and no value initialization. 
            See the <a href="make_shared_array.html">make_shared and allocate_shared for 
            arrays</a> page for more information.</p>
        <p>January 2002. Peter Dimov reworked all four classes, adding features, fixing
            bugs, and splitting them into four separate headers, and added <b>weak_ptr</b>.
            See the <a href="compatibility.htm">compatibility</a> page for a summary of the
            changes.</p>
        <p>May 2001. Vladimir Prus suggested requiring a complete type on destruction.
            Refinement evolved in discussions including Dave Abrahams, Greg Colvin, Beman
            Dawes, Rainer Deyke, Peter Dimov, John Maddock, Vladimir Prus, Shankar Sai, and
            others.</p>
        <p>November 1999. Darin Adler provided <b>operator ==</b>, <b>operator !=</b>, and <b>std::swap</b>
            and <b>std::less</b> specializations for shared types.</p>
        <p>September 1999. Luis Coelho provided <b>shared_ptr::swap</b> and <b>shared_array::swap</b></p>
        <p>May 1999. In April and May, 1999, Valentin Bonnard and David Abrahams made a
            number of suggestions resulting in numerous improvements.</p>
        <p>October 1998. Beman Dawes proposed reviving the original semantics under the
            names <b>safe_ptr</b> and <b>counted_ptr</b>, meeting of Per Andersson, Matt
            Austern, Greg Colvin, Sean Corfield, Pete Becker, Nico Josuttis, Dietmar K&uuml;hl,
            Nathan Myers, Chichiang Wan and Judy Ward. During the discussion, the four new
            class names were finalized, it was decided that there was no need to exactly
            follow the <b>std::auto_ptr</b> interface, and various function signatures and
            semantics were finalized.</p>
        <p>Over the next three months, several implementations were considered for <b>shared_ptr</b>,
            and discussed on the <a href="http://www.boost.org">boost.org</a> mailing list.
            The implementation questions revolved around the reference count which must be
            kept, either attached to the pointed to object, or detached elsewhere. Each of
            those variants have themselves two major variants:
            <ul>
                <li>
                Direct detached: the shared_ptr contains a pointer to the object, and a pointer
                to the count.
                <li>
                Indirect detached: the shared_ptr contains a pointer to a helper object, which
                in turn contains a pointer to the object and the count.
                <li>
                Embedded attached: the count is a member of the object pointed to.
                <li>
                Placement attached: the count is attached via operator new manipulations.</li>
            </ul>
        <p>Each implementation technique has advantages and disadvantages. We went so far
            as to run various timings of the direct and indirect approaches, and found that
            at least on Intel Pentium chips there was very little measurable difference.
            Kevlin Henney provided a paper he wrote on "Counted Body Techniques." Dietmar
            K&uuml;hl suggested an elegant partial template specialization technique to allow
            users to choose which implementation they preferred, and that was also
            experimented with.</p>
        <p>But Greg Colvin and Jerry Schwarz argued that "parameterization will discourage
            users", and in the end we choose to supply only the direct implementation.</p>
        <p>Summer, 1994. Greg Colvin proposed to the C++ Standards Committee classes named <b>auto_ptr</b>
            and <b>counted_ptr</b> which were very similar to what we now call <b>scoped_ptr</b>
            and <b>shared_ptr</b>. <a href="#Col-94">[Col-94]</a> In one of the very few
            cases where the Library Working Group's recommendations were not followed by
            the full committee, <b>counted_ptr</b> was rejected and surprising
            transfer-of-ownership semantics were added to <b>auto_ptr</b>.</p>
        <h2><a name="References">References</a></h2>
        <p>[<a name="D&amp;F-14">D&amp;F-14</a>] Peter Dimov &amp; Glen Fernandes, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3870.html">
            Extending make_shared to Support Arrays, Revision 1</a>, C++ committee document N3870,
            January, 2014.</p>
        <p>[<a name="Col-94">Col-94</a>] Gregory Colvin, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N0555.pdf">
            Exception Safe Smart Pointers</a>, C++ committee document 94-168/N0555,
            July, 1994.</p>
        <p>[<a name="E&amp;D-94">E&amp;D-94</a>] John R. Ellis &amp; David L. Detlefs, <a href="http://www.usenix.org/publications/library/proceedings/c++94/full_papers/ellis.a">
            Safe, Efficient Garbage Collection for C++</a>, Usenix Proceedings,
            February, 1994. This paper includes an extensive discussion of weak pointers
            and an extensive bibliography.</p>
        <hr>
        <p>$Date$</p>
        <p><small>Copyright 1999 Greg Colvin and Beman Dawes. Copyright 2002 Darin Adler.
            Distributed under the Boost Software License, Version 1.0. See accompanying
            file <A href="../../LICENSE_1_0.txt">LICENSE_1_0.txt</A> or copy at
            <A href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</A>.</small></p>
    </body>
</html>
Commit	Line	Data
7c673cae FG	1	<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
	2	<html>
	3	<head>
	4	<title>Smart Pointers</title>
	5	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	6	</head>
	7	<body text="#000000" bgcolor="#ffffff" link="#0000ff" vlink="#0000ff">
	8	<h1><img height="86" alt="boost.png (6897 bytes)" src="../../boost.png"
	9	width="277" align="middle" border="0">Smart Pointers</h1>
	10	<p><a href="#Introduction">Introduction</a><br>
	11	<a href="#common_requirements">Common Requirements</a><br>
	12	<a href="#Exception_Safety">Exception Safety</a><br>
	13	<a href="#Exception-specifications">Exception-specifications</a><br>
	14	<a href="#History">History and Acknowledgements</a><br>
	15	<a href="#References">References</a></p>
	16	<h2><a name="Introduction">Introduction</a></h2>
	17	<p>Smart pointers are objects which store pointers to dynamically allocated (heap)
	18	objects. They behave much like built-in C++ pointers except that they
	19	automatically delete the object pointed to at the appropriate time. Smart
	20	pointers are particularly useful in the face of exceptions as they ensure
	21	proper destruction of dynamically allocated objects. They can also be used to
	22	keep track of dynamically allocated objects shared by multiple owners.</p>
	23	<p>Conceptually, smart pointers are seen as owning the object pointed to, and thus
	24	responsible for deletion of the object when it is no longer needed.</p>
	25	<p>The smart pointer library provides six smart pointer class templates:</p>
	26	<div align="left">
	27	<table border="1" cellpadding="4" cellspacing="0">
	28	<tr>
	29	<td><a href="scoped_ptr.htm"><b>scoped_ptr</b></a></td>
	30	<td><a href="../../boost/scoped_ptr.hpp"><boost/scoped_ptr.hpp></a></td>
	31	<td>Simple sole ownership of single objects. Noncopyable.</td>
	32	</tr>
	33	<tr>
	34	<td><a href="scoped_array.htm"><b>scoped_array</b></a></td>
	35	<td><a href="../../boost/scoped_array.hpp"><boost/scoped_array.hpp></a></td>
	36	<td>Simple sole ownership of arrays. Noncopyable.</td>
	37	</tr>
	38	<tr>
	39	<td><a href="shared_ptr.htm"><b>shared_ptr</b></a></td>
	40	<td><a href="../../boost/shared_ptr.hpp"><boost/shared_ptr.hpp></a></td>
	41	<td>Object ownership shared among multiple pointers.</td>
	42	</tr>
	43	<tr>
	44	<td><a href="shared_array.htm"><b>shared_array</b></a></td>
	45	<td><a href="../../boost/shared_array.hpp"><boost/shared_array.hpp></a></td>
	46	<td>Array ownership shared among multiple pointers.</td>
	47	</tr>
	48	<tr>
	49	<td><a href="weak_ptr.htm"><b>weak_ptr</b></a></td>
	50	<td><a href="../../boost/weak_ptr.hpp"><boost/weak_ptr.hpp></a></td>
	51	<td>Non-owning observers of an object owned by <b>shared_ptr</b>.</td>
	52	</tr>
	53	<tr>
	54	<td><a href="intrusive_ptr.html"><b>intrusive_ptr</b></a></td>
	55	<td><a href="../../boost/intrusive_ptr.hpp"><boost/intrusive_ptr.hpp></a></td>
	56	<td>Shared ownership of objects with an embedded reference count.</td>
	57	</tr>
	58	</table>
	59	</div>
	60	<p>These templates are designed to complement the <b>std::auto_ptr</b> template.</p>
	61	<p>They are examples of the "resource acquisition is initialization" idiom
	62	described in Bjarne Stroustrup's "The C++ Programming Language", 3rd edition,
	63	Section 14.4, Resource Management.</p>
	64	<p>Additionally, the smart pointer library provides efficient factory functions
65	for creating smart pointer objects:</p>
66	<div align="left">
67	<table border="1" cellpadding="4" cellspacing="0">
68	<tr>
69	<td><a href="make_shared.html"><b>make_shared, allocate_shared</b></a> for objects</td>
70	<td><a href="../../boost/make_shared.hpp"><boost/make_shared.hpp></a></td>
71	<td>Efficient creation of <code>shared_ptr</code> objects.</td>
72	</tr>
73	<tr>
74	<td><a href="make_shared_array.html"><b>make_shared, allocate_shared</b></a> for arrays</td>
75	<td><a href="../../boost/make_shared.hpp"><boost/make_shared.hpp></a></td>
76	<td>Efficient creation of <code>shared_ptr</code> arrays.</td>
77	</tr>
78	<tr>
79	<td><a href="make_unique.html"><b>make_unique</b></a></td>
80	<td><a href="../../boost/make_unique.hpp"><boost/make_unique.hpp></a></td>
81	<td>Creation of <code>unique_ptr</code> objects and arrays.</td>
82	</tr>
83	</table>
84	</div>
85	<p>A test program, <a href="test/smart_ptr_test.cpp">smart_ptr_test.cpp</a>, is
86	provided to verify correct operation.</p>
87	<p>A page on <a href="compatibility.htm">compatibility</a> with older versions of
88	the Boost smart pointer library describes some of the changes since earlier
89	versions of the smart pointer implementation.</p>
90	<p>A page on <a href="smarttests.htm">smart pointer timings</a> will be of interest
91	to those curious about performance issues.</p>
92	<P>A page on <A href="sp_techniques.html">smart pointer programming techniques</A> lists
93	some advanced applications of <code>shared_ptr</code> and <code>weak_ptr</code>.</P>
94	<h2><a name="common_requirements">Common Requirements</a></h2>
95	<p>These smart pointer class templates have a template parameter, <b>T</b>, which
96	specifies the type of the object pointed to by the smart pointer. The behavior
97	of the smart pointer templates is undefined if the destructor or <b>operator delete</b>
98	for objects of type <b>T</b> throw exceptions.</p>
99	<p><b>T</b> may be an incomplete type at the point of smart pointer declaration.
100	Unless otherwise specified, it is required that <b>T</b> be a complete type at
101	points of smart pointer instantiation. Implementations are required to diagnose
102	(treat as an error) all violations of this requirement, including deletion of
103	an incomplete type. See the description of the <a href="../utility/utility.htm#checked_delete">
104	<b>checked_delete</b></a> function template.</p>
105	<P>Note that <STRONG>shared_ptr</STRONG> does not have this restriction, as most of
106	its member functions do not require <STRONG>T</STRONG> to be a complete type.</P>
107	<h3>Rationale</h3>
108	<p>The requirements on <b>T</b> are carefully crafted to maximize safety yet allow
109	handle-body (also called pimpl) and similar idioms. In these idioms a smart
110	pointer may appear in translation units where <b>T</b> is an incomplete type.
111	This separates interface from implementation and hides implementation from
112	translation units which merely use the interface. Examples described in the
113	documentation for specific smart pointers illustrate use of smart pointers in
114	these idioms.</p>
115	<p>Note that <b>scoped_ptr</b> requires that <b>T</b> be a complete type at
116	destruction time, but <b>shared_ptr</b> does not.</p>
117	<h2><a name="Exception_Safety">Exception Safety</a></h2>
118	<p>Several functions in these smart pointer classes are specified as having "no
119	effect" or "no effect except such-and-such" if an exception is thrown. This
120	means that when an exception is thrown by an object of one of these classes,
121	the entire program state remains the same as it was prior to the function call
122	which resulted in the exception being thrown. This amounts to a guarantee that
123	there are no detectable side effects. Other functions never throw exceptions.
124	The only exception ever thrown by functions which do throw (assuming <b>T</b> meets
125	the <a href="#common_requirements">common requirements</a>) is <b>std::bad_alloc</b>,
126	and that is thrown only by functions which are explicitly documented as
127	possibly throwing <b>std::bad_alloc</b>.</p>
128	<h2><a name="Exception-specifications">Exception-specifications</a></h2>
129	<p>Exception-specifications are not used; see <a href="http://www.boost.org/more/lib_guide.htm#Exception-specification">
130	exception-specification rationale</a>.</p>
131	<p>All the smart pointer templates contain member functions which can never throw
132	exceptions, because they neither throw exceptions themselves nor call other
133	functions which may throw exceptions. These members are indicated by a comment: <code>
134	// never throws</code>.
135	</p>
136	<p>Functions which destroy objects of the pointed to type are prohibited from
137	throwing exceptions by the <a href="#common_requirements">common requirements</a>.</p>
138	<h2><a name="History">History</a> and Acknowledgements</h2>
139	<p>February 2014. Glen Fernandes updated overloads of <b>make_shared</b> and
140	<b>allocate_shared</b> to conform to the specification in C++ standard paper
141	<a href="#D&F-14">[D&F-14]</a>, and implemented <b>make_unique</b> for
142	arrays and objects. Peter Dimov and Glen Fernandes updated the scalar and
143	array implementations, respectively, to resolve C++ standard library defect
144	2070.</p>
145	<p>November 2012. Glen Fernandes provided implementations of <b>make_shared</b>
146	and <b>allocate_shared</b> for arrays. They achieve a single allocation for an
147	array that can be initialized with constructor arguments or initializer lists
148	as well as overloads for default initialization and no value initialization.
149	See the <a href="make_shared_array.html">make_shared and allocate_shared for
150	arrays</a> page for more information.</p>
151	<p>January 2002. Peter Dimov reworked all four classes, adding features, fixing
152	bugs, and splitting them into four separate headers, and added <b>weak_ptr</b>.
153	See the <a href="compatibility.htm">compatibility</a> page for a summary of the
154	changes.</p>
155	<p>May 2001. Vladimir Prus suggested requiring a complete type on destruction.
156	Refinement evolved in discussions including Dave Abrahams, Greg Colvin, Beman
157	Dawes, Rainer Deyke, Peter Dimov, John Maddock, Vladimir Prus, Shankar Sai, and
158	others.</p>
159	<p>November 1999. Darin Adler provided <b>operator ==</b>, <b>operator !=</b>, and <b>std::swap</b>
160	and <b>std::less</b> specializations for shared types.</p>
161	<p>September 1999. Luis Coelho provided <b>shared_ptr::swap</b> and <b>shared_array::swap</b></p>
162	<p>May 1999. In April and May, 1999, Valentin Bonnard and David Abrahams made a
163	number of suggestions resulting in numerous improvements.</p>
164	<p>October 1998. Beman Dawes proposed reviving the original semantics under the
165	names <b>safe_ptr</b> and <b>counted_ptr</b>, meeting of Per Andersson, Matt
166	Austern, Greg Colvin, Sean Corfield, Pete Becker, Nico Josuttis, Dietmar Kühl,
167	Nathan Myers, Chichiang Wan and Judy Ward. During the discussion, the four new
168	class names were finalized, it was decided that there was no need to exactly
169	follow the <b>std::auto_ptr</b> interface, and various function signatures and
170	semantics were finalized.</p>
171	<p>Over the next three months, several implementations were considered for <b>shared_ptr</b>,
172	and discussed on the <a href="http://www.boost.org">boost.org</a> mailing list.
173	The implementation questions revolved around the reference count which must be
174	kept, either attached to the pointed to object, or detached elsewhere. Each of
175	those variants have themselves two major variants:
176	<ul>
177	<li>
178	Direct detached: the shared_ptr contains a pointer to the object, and a pointer
179	to the count.
180	<li>
181	Indirect detached: the shared_ptr contains a pointer to a helper object, which
182	in turn contains a pointer to the object and the count.
183	<li>
184	Embedded attached: the count is a member of the object pointed to.
185	<li>
186	Placement attached: the count is attached via operator new manipulations.</li>
187	</ul>
188	<p>Each implementation technique has advantages and disadvantages. We went so far
189	as to run various timings of the direct and indirect approaches, and found that
190	at least on Intel Pentium chips there was very little measurable difference.
191	Kevlin Henney provided a paper he wrote on "Counted Body Techniques." Dietmar
192	Kühl suggested an elegant partial template specialization technique to allow
193	users to choose which implementation they preferred, and that was also
194	experimented with.</p>
195	<p>But Greg Colvin and Jerry Schwarz argued that "parameterization will discourage
196	users", and in the end we choose to supply only the direct implementation.</p>
197	<p>Summer, 1994. Greg Colvin proposed to the C++ Standards Committee classes named <b>auto_ptr</b>
198	and <b>counted_ptr</b> which were very similar to what we now call <b>scoped_ptr</b>
199	and <b>shared_ptr</b>. <a href="#Col-94">[Col-94]</a> In one of the very few
200	cases where the Library Working Group's recommendations were not followed by
201	the full committee, <b>counted_ptr</b> was rejected and surprising
202	transfer-of-ownership semantics were added to <b>auto_ptr</b>.</p>
203	<h2><a name="References">References</a></h2>
204	<p>[<a name="D&F-14">D&F-14</a>] Peter Dimov & Glen Fernandes, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3870.html">
205	Extending make_shared to Support Arrays, Revision 1</a>, C++ committee document N3870,
206	January, 2014.</p>
207	<p>[<a name="Col-94">Col-94</a>] Gregory Colvin, <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/1994/N0555.pdf">
208	Exception Safe Smart Pointers</a>, C++ committee document 94-168/N0555,
209	July, 1994.</p>
210	<p>[<a name="E&D-94">E&D-94</a>] John R. Ellis & David L. Detlefs, <a href="http://www.usenix.org/publications/library/proceedings/c++94/full_papers/ellis.a">
211	Safe, Efficient Garbage Collection for C++</a>, Usenix Proceedings,
212	February, 1994. This paper includes an extensive discussion of weak pointers
213	and an extensive bibliography.</p>
214	<hr>
215	<p>$Date$</p>
216	<p><small>Copyright 1999 Greg Colvin and Beman Dawes. Copyright 2002 Darin Adler.
217	Distributed under the Boost Software License, Version 1.0. See accompanying
218	file <A href="../../LICENSE_1_0.txt">LICENSE_1_0.txt</A> or copy at
219	<A href="http://www.boost.org/LICENSE_1_0.txt">http://www.boost.org/LICENSE_1_0.txt</A>.</small></p>
220	</body>
221	</html>