Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The standard was finalized in 1998 with fixes in 2003, whereas <code>boost::addressof</code> <a href="http://boost.cvs.sourceforge.net/viewvc/boost/boost/libs/utility/utility.htm?view=log" rel="nofollow noreferrer">dates to</a> early 2002.</p> <p>Moreover, it's not clear that <code>addressof</code> is the answer. Overloads of <code>operator&amp;()</code> indicate that raw pointers are supposed to be avoided. The <code>Allocator::address</code> member provides the best interface to get from <code>Allocator::reference</code> to <code>Allocator::pointer</code>, so in general theory, you should be able to effectively <em>introduce</em> an <code>operator&amp;</code> override to an otherwise well-behaved class with a custom allocator.</p> <p>Considering that references do almost everything that pointers do, and the Allocator interface abstracts everything else, there should be no need for raw pointers.</p> <p>Convenience to the library implementers should not be an issue. The ill-defined semantics of <code>Allocator::pointer</code> are a problem, and what I've read so far in C++0x doesn't clear that up.</p> <p>C++0x removes any mention of <code>operator&amp;</code> from CopyConstructible, and furthermore doesn't require anything-Constructible for container arguments at all — the user can stick to <code>emplace</code>. Even <code>vector</code> only requires Destructible, although I suppose actually using <code>insert</code> or <code>erase</code> would require more.</p> <p>(Note that, in the strictest reading, overloads are not forbidden in C++03. You are just not allowed to change the value or type of the builtin.)</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload