<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 580: unused allocator members</title>
<meta property="og:title" content="Issue 580: unused allocator members">
<meta property="og:description" content="C++ library issue. Status: NAD Editorial">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue580.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#NAD_Editorial">NAD Editorial</a> status.</em></p>
<h3 id="580"><a href="lwg-closed.html#580">580</a>. unused allocator members</h3>
<p><b>Section:</b> 23.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> <b>Status:</b> <a href="lwg-active.html#NAD_Editorial">NAD Editorial</a>
 <b>Submitter:</b> Martin Sebor <b>Opened:</b> 2006-06-14 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#NAD Editorial">NAD Editorial</a> status.</p>
<p><b>Duplicate of:</b> <a href="lwg-closed.html#479" title="Container requirements and placement new (Status: Dup)">479</a></p>
<p><b>Discussion:</b></p>
<p>

C++ Standard Library  templates that take an allocator  as an argument
are    required    to    call    the    <code>allocate()</code>    and
<code>deallocate()</code>  members of the  allocator object  to obtain
storage.  However, they do not appear to be required to call any other
allocator      members      such     as      <code>construct()</code>,
<code>destroy()</code>,           <code>address()</code>,          and
<code>max_size()</code>.  This makes these allocator members less than
useful in portable programs.

        </p>
        <p>

It's unclear to me whether the absence of the requirement to use these
allocator  members  is  an  unintentional  omission  or  a  deliberate
choice. However,  since the functions exist in  the standard allocator
and  since  they are  required  to  be  provided by  any  user-defined
allocator I  believe the standard  ought to be clarified  to explictly
specify  whether programs  should or  should not  be able  to  rely on
standard containers calling the functions.

        </p>
        <p>

I  propose  that all  containers  be required  to  make  use of  these
functions.

        </p>
<p><i>[
Batavia:  We support this resolution.  Martin to provide wording.
]</i></p>

<p><i>[
pre-Oxford:  Martin provided wording.
]</i></p>


<p><i>[
2009-04-28 Pablo adds:
]</i></p>


<blockquote><p>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2554.pdf">N2554</a>
(scoped allocators),
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2768.pdf">N2768</a>
(allocator concepts), and
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2810.pdf">N2810</a>
(allocator defects), address all of these points EXCEPT <code>max_size()</code>.
So, I would add a note to that affect and re-class the defect as belonging
to section 23.2.2 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>.
</p></blockquote>

<p><i>[
2009-07 Frankfurt
]</i></p>


<blockquote><p>
The comment in the description of this issue that this "would be"
rendered editorial by the adoption of N2257 is confusing. It appears
that N2257 was never adopted.
</p></blockquote>

<p><i>[
2009-10 Santa Cruz:
]</i></p>


<blockquote><p>
NAD Editorial.  Addressed by
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf">N2982</a>.
</p></blockquote>



    <p id="res-580"><b>Proposed resolution:</b></p>
       <p>

Specifically, I propose to change 23.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a>,
p9 as follows:

       </p>
           <blockquote>
<p>
-9- Copy constructors  for all container types defined  in this clause
<ins>that   are  parametrized  on   <code>Allocator</code></ins>  copy
<del>an</del><ins>the</ins>  allocator argument from  their respective
first parameters.

All other  constructors for  these container types  take a<del>n</del>
<ins>const</ins>  <code>Allocator&amp;</code>  argument  (20.1.6),  an
allocator whose <code>value_type</code> is the same as the container's
<code>value_type</code>.

A copy of this  argument <del>is</del><ins>shall be</ins> used for any
memory  allocation <ins> and  deallocation</ins> performed<del>,</del>
by these  constructors and by all  member functions<del>,</del> during
the  lifetime  of each  container  object.   <ins>Allocation shall  be
performed  "as  if"  by  calling  the  <code>allocate()</code>  member
function on  a copy  of the allocator  object of the  appropriate type
<sup>New  Footnote)</sup>,   and  deallocation  "as   if"  by  calling
<code>deallocate()</code> on  a copy of  the same allocator  object of
the corresponding type.</ins>

<ins>A  copy of  this argument  shall also  be used  to  construct and
destroy objects whose lifetime  is managed by the container, including
but not  limited to those of  the container's <code>value_type</code>,
and  to  obtain  their  address.   All  objects  residing  in  storage
allocated by a  container's allocator shall be constructed  "as if" by
calling the <code>construct()</code> member  function on a copy of the
allocator object of  the appropriate type.  The same  objects shall be
destroyed "as if"  by calling <code>destroy()</code> on a  copy of the
same allocator object  of the same type.  The  address of such objects
shall be obtained "as if" by calling the <code>address()</code> member
function  on  a  copy  of  the allocator  object  of  the  appropriate
type.</ins>

<ins>Finally, a copy  of this argument shall be  used by its container
object to determine  the maximum number of objects  of the container's
<code>value_type</code> the container may  store at the same time. The
container  member function <code>max_size()</code> obtains  this number
from      the      value      returned      by     a      call      to
<code>get_allocator().max_size()</code>.</ins>

In   all  container   types  defined   in  this   clause <ins>that  are
parametrized     on    <code>Allocator</code></ins>,     the    member
<code>get_allocator()</code>     returns     a     copy     of     the
<code>Allocator</code>     object     used     to    construct     the
container.<sup>258)</sup>
</p>
<p>
New Footnote: This type  may be different from <code>Allocator</code>:
it     may    be     derived    from     <code>Allocator</code>    via
<code>Allocator::rebind&lt;U&gt;::other</code>   for  the  appropriate
type <code>U</code>.
</p>
           </blockquote>
       <p>

The proposed wording seems cumbersome but I couldn't think of a better
way   to  describe   the   requirement  that   containers  use   their
<code>Allocator</code>  to manage  only objects  (regardless  of their
type)  that  persist  over  their  lifetimes  and  not,  for  example,
temporaries  created on the  stack. That  is, containers  shouldn't be
required  to  call  <code>Allocator::construct(Allocator::allocate(1),
elem)</code>  just to  construct a  temporary copy  of an  element, or
<code>Allocator::destroy(Allocator::address(temp),     1)</code>    to
destroy temporaries.

       </p>


<p><i>[
Howard: This same paragraph will need some work to accommodate <a href="lwg-defects.html#431" title="Swapping containers with unequal allocators (Status: Resolved)">431</a><sup><a href="https://cplusplus.github.io/LWG/issue431" title="Latest snapshot">(i)</a></sup>.
]</i></p>


<p><i>[
post Oxford:  This would be rendered NAD Editorial by acceptance of
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2257.html">N2257</a>.
]</i></p>





</body>
</html>
