utility/noncopyable : fix #6578.

[SVN r83869]
This commit is contained in:
Vicente J. Botet Escriba 2013-04-13 13:49:52 +00:00
parent 2eda3f5299
commit 4080fe22e3
2 changed files with 22 additions and 6 deletions

View File

@ -9,6 +9,8 @@
#ifndef BOOST_NONCOPYABLE_HPP_INCLUDED #ifndef BOOST_NONCOPYABLE_HPP_INCLUDED
#define BOOST_NONCOPYABLE_HPP_INCLUDED #define BOOST_NONCOPYABLE_HPP_INCLUDED
#include <boost/config.hpp>
namespace boost { namespace boost {
// Private copy constructor and copy assignment ensure classes derived from // Private copy constructor and copy assignment ensure classes derived from
@ -21,11 +23,21 @@ namespace noncopyable_ // protection from unintended ADL
class noncopyable class noncopyable
{ {
protected: protected:
noncopyable() {} #ifndef BOOST_NO_DEFAULTED_FUNCTIONS
BOOST_CONSTEXPR noncopyable() = default;
~noncopyable() = default;
#else
noncopyable() {}
~noncopyable() {} ~noncopyable() {}
private: // emphasize the following members are private #endif
#ifndef BOOST_NO_DELETED_FUNCTIONS
noncopyable( const noncopyable& ) = delete;
noncopyable& operator=( const noncopyable& ) = delete;
#else
private: // emphasize the following members are private
noncopyable( const noncopyable& ); noncopyable( const noncopyable& );
const noncopyable& operator=( const noncopyable& ); noncopyable& operator=( const noncopyable& );
#endif
}; };
} }

View File

@ -84,8 +84,10 @@ const std::list&lt;T&gt;::iterator next = boost::next(prev, 2);</pre>
will prevent the otherwise implicitly-generated functions (which don't have the will prevent the otherwise implicitly-generated functions (which don't have the
proper semantics) from becoming a trap for other programmers.</p> proper semantics) from becoming a trap for other programmers.</p>
<p>The traditional way to deal with these is to declare a private copy constructor <p>The traditional way to deal with these is to declare a private copy constructor
and copy assignment, and then document why this is done.&nbsp; But deriving and copy assignment, and then document why this is done.&nbsp; A new alternative
from <b>noncopyable</b> is simpler and clearer, and doesn't require additional was introduced in C++2011, declaring a copy constructor and a copy assignment
operator, but marking both as <code>delete</code>d.&nbsp; Deriving
from <b>noncopyable</b> is simpler and clearer, and doesn't require additional
documentation.</p> documentation.</p>
<p>The program <a href="noncopyable_test.cpp">noncopyable_test.cpp</a> can be used <p>The program <a href="noncopyable_test.cpp">noncopyable_test.cpp</a> can be used
to verify class <b>noncopyable</b> works as expected. It has have been run to verify class <b>noncopyable</b> works as expected. It has have been run
@ -106,7 +108,9 @@ class ResourceLadenFileSystem : boost::noncopyable {
about the effect on compiler optimization of adding (even trivial inline) about the effect on compiler optimization of adding (even trivial inline)
destructor declarations. He says &quot;Probably this concern is misplaced, destructor declarations. He says &quot;Probably this concern is misplaced,
because noncopyable will be used mostly for classes which own resources and because noncopyable will be used mostly for classes which own resources and
thus have non-trivial destruction semantics.&quot;</p> thus have non-trivial destruction semantics.&quot;&nbsp; With C++2011, using an
optimized and trivial constructor and similar destructor can be enforced by
declaring both and marking them <code>default</code>.</p>
<h2><a name="addressof">Function template addressof()</a></h2> <h2><a name="addressof">Function template addressof()</a></h2>
<p>Function <strong>addressof()</strong> returns the address of an object.</p> <p>Function <strong>addressof()</strong> returns the address of an object.</p>
<blockquote> <blockquote>