------=_Part_4752_1540503951.1430797271855
Content-Type: multipart/alternative;
 boundary="----=_Part_4753_1187056225.1430797271855"

------=_Part_4753_1187056225.1430797271855
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Have =
Your=20
Non-Moveable Types Covered"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf

He proposes a new member function of std::vector<T> whose name is "subject=
=20
to L(E)WG bikeshedding" but tentatively proposed as std::vector<T>::reserve=
_initially(size_type=20
n). The semantics of this function would be *(A)*

    if empty()
        reserve space for exactly n elements
    else
        throw an exception

This is contrasted with the current behavior (since C++98) of std::vector<T=
>::reserve(size_type=20
n), whose semantics are *(B)*

    if capacity() < n
        reserve space for at least n elements
    else
        do nothing

I have often wished for a member function of std::vector<T> that could give=
=20
me a vector with capacity exactly n and no more =E2=80=94 for example, if I=
 know my=20
vector's maximum capacity up front and I want to be economical with my=20
memory usage; or if I'm using a user-defined allocator that is good at=20
allocating blocks of one exact size and bad at bigger sizes.

Surely it has occurred to everybody on the Committee by now that it would=
=20
be super convenient if std::vector<T>::reserve *were* that function; i.e.,=
=20
if we changed its semantics from *(B)* above to *(C)*

    if capacity() < n
        reserve space for exactly n elements
    else
        do nothing

However, in 17 years, this change has not happened. This suggests that=20
there's a really good reason for its not happening. What is that reason?=20
Clearly one reason would be "vendor inertia", but vendors are doing pretty=
=20
well these days at keeping up with library changes, so maybe that shouldn't=
=20
be the *only* blocking reason.

Does anyone on the Committee have some inside information on the reasons=20
for vector::reserve's current (IMHO suboptimal) specification?

Finally, let me open the bikeshed by suggesting that if semantics *(C)*=20
can't be given to vector::reserve(size_type n), they should at least be=20
given to a new overload vector::reserve(size_type n,=20
decltype(std::reserve_exactly)).  Either way, I see no reason for N4416's=
=20
proposed semantics *(A)* to ever make it into the language; they just seem=
=20
strictly less useful and less efficient than semantics *(C)*.

Thoughts?
=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_4753_1187056225.1430797271855
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I've been reading Nevin Liber's N4416&nbsp;"Don=E2=80=99t =
Move: vector Can Have Your Non-Moveable Types Covered"<br><div><div class=
=3D"page" title=3D"Page 1"><div class=3D"layoutArea"><div class=3D"column">=
</div></div></div></div><div>http://www.open-std.org/jtc1/sc22/wg21/docs/pa=
pers/2015/n4416.pdf<br><div><br></div></div><div>He proposes a new member f=
unction of <font face=3D"courier new, monospace">std::vector&lt;T&gt;</font=
> whose name is "subject to L(E)WG bikeshedding" but tentatively proposed a=
s <font face=3D"courier new, monospace">std::vector&lt;T&gt;::reserve_initi=
ally(size_type n)</font>. The semantics of this function would be <b>(A)</b=
></div><div><br></div><div><font face=3D"courier new, monospace">&nbsp; &nb=
sp; if empty()</font></div><div><font face=3D"courier new, monospace">&nbsp=
; &nbsp; &nbsp; &nbsp; reserve space for exactly n elements</font></div><di=
v><font face=3D"courier new, monospace">&nbsp; &nbsp; else</font></div><div=
><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; throw an=
 exception</font></div><div><br></div><div>This is contrasted with the curr=
ent behavior (since C++98) of <font face=3D"courier new, monospace">std::ve=
ctor&lt;T&gt;::reserve(size_type n)</font>, whose semantics are <b>(B)</b><=
/div><div><br></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp=
; if capacity() &lt; n</font></div><div><font face=3D"courier new, monospac=
e">&nbsp; &nbsp; &nbsp; &nbsp; reserve space for at least n elements</font>=
</div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; else</font><=
/div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp;=
 do nothing</font></div><div><br></div><div>I have often wished for a membe=
r function of <font face=3D"courier new, monospace">std::vector&lt;T&gt;</f=
ont> that could give me a vector with capacity exactly <font face=3D"courie=
r new, monospace">n</font>&nbsp;and no more =E2=80=94 for example, if I kno=
w my vector's maximum capacity up front and I want to be economical with my=
 memory usage; or if I'm using a user-defined allocator that is good at all=
ocating blocks of one exact size and bad at bigger sizes.</div><div><br></d=
iv><div>Surely it has occurred to everybody on the Committee by now that it=
 would be super convenient if <font face=3D"courier new, monospace">std::ve=
ctor&lt;T&gt;::reserve</font> <b><i>were</i></b> that function; i.e., if we=
 changed its semantics from <b>(B)</b> above to <b>(C)</b></div><div><br></=
div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; if capacity() =
&lt; n</font></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp;=
 &nbsp; &nbsp; reserve space for exactly n elements</font></div><div><font =
face=3D"courier new, monospace">&nbsp; &nbsp; else</font></div><div><font f=
ace=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; do nothing</font=
></div><div><br></div><div>However, in 17 years, this change has not happen=
ed. This suggests that there's a really good reason for its not happening. =
What is that reason? Clearly one reason would be "vendor inertia", but vend=
ors are doing pretty well these days at keeping up with library changes, so=
 maybe that shouldn't be the <i>only</i> blocking reason.</div><div><br></d=
iv><div>Does anyone on the Committee have some inside information on the re=
asons for <font face=3D"courier new, monospace">vector::reserve</font>'s cu=
rrent (IMHO suboptimal) specification?</div><div><br></div><div>Finally, le=
t me open the bikeshed by suggesting that if semantics <b>(C)</b> can't be =
given to <font face=3D"courier new, monospace">vector::reserve(size_type n)=
</font>, they should at least be given to a new overload&nbsp;<font face=3D=
"courier new, monospace">vector::reserve(size_type n, decltype(std::reserve=
_exactly))</font>. &nbsp;Either way, I see no reason for N4416's proposed s=
emantics <b>(A)</b> to ever make it into the language; they just seem stric=
tly less useful and less efficient than semantics <b>(C)</b>.</div><div><br=
></div><div>Thoughts?</div><div>=E2=80=93Arthur</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4753_1187056225.1430797271855--
------=_Part_4752_1540503951.1430797271855--

.

--001a113cdb9819509f05154e9c2f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 4 May 2015 at 22:41, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

> I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Hav=
e Your
> Non-Moveable Types Covered"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
>

That paper looks familiar. :-)


> I have often wished for a member function of std::vector<T> that could
> give me a vector with capacity exactly n and no more =E2=80=94 for exampl=
e, if I
> know my vector's maximum capacity up front and I want to be economical wi=
th
> my memory usage; or if I'm using a user-defined allocator that is good at
> allocating blocks of one exact size and bad at bigger sizes.
>

Even if you have a user-defined allocator with those properties, there
really is no way (other than specializing vector on the allocator type) for
vector to communicate with the allocator to determine the optimal block
size to use.  The vector keeps track of capacity independent of the
allocator.


> Surely it has occurred to everybody on the Committee by now that it would
> be super convenient if std::vector<T>::reserve *were* that function;
> i.e., if we changed its semantics from *(B)* above to *(C)*
>
>     if capacity() < n
>         reserve space for exactly n elements
>     else
>         do nothing
>
> However, in 17 years, this change has not happened. This suggests that
> there's a really good reason for its not happening. What is that reason?
> Clearly one reason would be "vendor inertia", but vendors are doing prett=
y
> well these days at keeping up with library changes, so maybe that shouldn=
't
> be the *only* blocking reason.
>

The committee works on proposals.  I don't know if anyone has proposed this
in the past.  I can see a few reasons:

1.  AFAIK implementations just pass the reserve size to the allocator
anyway.
2.  vector<bool> cannot enforce this w/o more bookkeeping.
3.  It isn't all that useful w/o something like emplace_back_capped() (or
something convoluted like a stateful allocator that allows exactly one
allocation).


> Does anyone on the Committee have some inside information on the reasons
> for vector::reserve's current (IMHO suboptimal) specification?
>

I have no knowledge (others around Lenexa might), but my guess is that the
initial design was made to maximize vendor freedom.  IIRC vector wasn't
initially required to have contiguous space.


> Finally, let me open the bikeshed by suggesting that if semantics *(C)*
> can't be given to vector::reserve(size_type n), they should at least be
> given to a new overload vector::reserve(size_type n,
> decltype(std::reserve_exactly)).  Either way, I see no reason for N4416's
> proposed semantics *(A)* to ever make it into the language; they just
> seem strictly less useful and less efficient than semantics *(C)*.
>

With (C) you cannot store non-moveable types, because the real algorithm is=
:

if capacity() < n
    reserve space for exactly n elements
    *move_if_noexcept elements from old space to new space*
    destroy elements in old space
    release old space
else
    do nothing

Various ideas are now floating around for setting exact reserve capacity.
We'll see if any of them survive after the presentation of this paper later
this week.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113cdb9819509f05154e9c2f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 4 May 2015 at 22:41, Arthur O&#39;Dwyer <span dir=3D"lt=
r">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthu=
r.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&=
#39;ve been reading Nevin Liber&#39;s N4416=C2=A0&quot;Don=E2=80=99t Move: =
vector Can Have Your Non-Moveable Types Covered&quot;<br><div><div title=3D=
"Page 1"><div><div></div></div></div></div><div><a href=3D"http://www.open-=
std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf" target=3D"_blank">http:/=
/www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf</a></div></div>=
</blockquote><div><br></div><div>That paper looks familiar. :-)</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I have oft=
en wished for a member function of <font face=3D"courier new, monospace">st=
d::vector&lt;T&gt;</font> that could give me a vector with capacity exactly=
 <font face=3D"courier new, monospace">n</font>=C2=A0and no more =E2=80=94 =
for example, if I know my vector&#39;s maximum capacity up front and I want=
 to be economical with my memory usage; or if I&#39;m using a user-defined =
allocator that is good at allocating blocks of one exact size and bad at bi=
gger sizes.<br></div></div></blockquote><div><br></div><div>Even if you hav=
e a user-defined allocator with those properties, there really is no way (o=
ther than specializing vector on the allocator type) for vector to communic=
ate with the allocator to determine the optimal block size to use.=C2=A0 Th=
e vector keeps track of capacity independent of the allocator.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div=
>Surely it has occurred to everybody on the Committee by now that it would =
be super convenient if <font face=3D"courier new, monospace">std::vector&lt=
;T&gt;::reserve</font> <b><i>were</i></b> that function; i.e., if we change=
d its semantics from <b>(B)</b> above to <b>(C)</b><br></div><div><br></div=
><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if capacity() &lt=
; n</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 reserve space for exactly n elements</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 else</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 do nothing</font>=
</div><div><br></div><div>However, in 17 years, this change has not happene=
d. This suggests that there&#39;s a really good reason for its not happenin=
g. What is that reason? Clearly one reason would be &quot;vendor inertia&qu=
ot;, but vendors are doing pretty well these days at keeping up with librar=
y changes, so maybe that shouldn&#39;t be the <i>only</i> blocking reason.<=
/div></div></blockquote><div><br></div><div>The committee works on proposal=
s.=C2=A0 I don&#39;t know if anyone has proposed this in the past.=C2=A0 I =
can see a few reasons:</div><div><br></div><div>1.=C2=A0 AFAIK implementati=
ons just pass the reserve size to the allocator anyway.</div><div>2. =C2=A0=
vector&lt;bool&gt; cannot enforce this w/o more bookkeeping.</div><div>3.=
=C2=A0 It isn&#39;t all that useful w/o something like emplace_back_capped(=
) (or something convoluted like a stateful allocator that allows exactly on=
e allocation).</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div>Does anyone on the Committee have some inside information on=
 the reasons for <font face=3D"courier new, monospace">vector::reserve</fon=
t>&#39;s current (IMHO suboptimal) specification?<br></div></div></blockquo=
te><div><br></div><div>I have no knowledge (others around Lenexa might), bu=
t my guess is that the initial design was made to maximize vendor freedom.=
=C2=A0 IIRC vector wasn&#39;t initially required to have contiguous space.<=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
</div><div>Finally, let me open the bikeshed by suggesting that if semantic=
s <b>(C)</b> can&#39;t be given to <font face=3D"courier new, monospace">ve=
ctor::reserve(size_type n)</font>, they should at least be given to a new o=
verload=C2=A0<font face=3D"courier new, monospace">vector::reserve(size_typ=
e n, decltype(std::reserve_exactly))</font>.=C2=A0 Either way, I see no rea=
son for N4416&#39;s proposed semantics <b>(A)</b> to ever make it into the =
language; they just seem strictly less useful and less efficient than seman=
tics <b>(C)</b>.<br></div></div></blockquote><div><br></div><div>With (C) y=
ou cannot store non-moveable types, because the real algorithm is:</div><di=
v><br></div><div>if capacity() &lt; n</div><div>=C2=A0 =C2=A0 reserve space=
 for exactly n elements</div><div>=C2=A0 =C2=A0 <b><i>move_if_noexcept elem=
ents from old space to new space</i></b></div><div>=C2=A0 =C2=A0 destroy el=
ements in old space</div><div>=C2=A0 =C2=A0 release old space</div><div>els=
e</div><div>=C2=A0 =C2=A0 do nothing</div><div><br></div><div>Various ideas=
 are now floating around for setting exact reserve capacity.=C2=A0 We&#39;l=
l see if any of them survive after the presentation of this paper later thi=
s week.</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;=
:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" =
target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113cdb9819509f05154e9c2f--

.

------=_Part_5139_765132860.1430816663363
Content-Type: multipart/alternative;
 boundary="----=_Part_5140_455899784.1430816663363"

------=_Part_5140_455899784.1430816663363
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Monday, May 4, 2015 at 10:04:15 PM UTC-7, Nevin ":-)" Liber wrote:
>
> On 4 May 2015 at 22:41, Arthur O'Dwyer <arthur....@gmail.com <javascript:=
>
> > wrote:
>
>> I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Ha=
ve Your=20
>> Non-Moveable Types Covered"
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
>>
>
> That paper looks familiar. :-)
> =20
>
>> I have often wished for a member function of std::vector<T> that could=
=20
>> give me a vector with capacity exactly n and no more =E2=80=94 for examp=
le, if I=20
>> know my vector's maximum capacity up front and I want to be economical w=
ith=20
>> my memory usage; or if I'm using a user-defined allocator that is good a=
t=20
>> allocating blocks of one exact size and bad at bigger sizes.
>>
>
> Even if you have a user-defined allocator with those properties, there=20
> really is no way (other than specializing vector on the allocator type) f=
or=20
> vector to communicate with the allocator to determine the optimal block=
=20
> size to use.  The vector keeps track of capacity independent of the=20
> allocator.
>

Right, but I'm *also* the guy writing the client code that reserves the=20
vector! So I might have something like
http://melpon.org/wandbox/permlink/skNNYpHPIr2v42iL
where I know that my allocator will return usable memory iff it is called=
=20
with the right arguments, but I cannot rely on the std::vector=20
implementation to actually *pass* those arguments, even when it's "obvious"=
=20
what should happen.

=20

> =20
>
>> Surely it has occurred to everybody on the Committee by now that it woul=
d=20
>> be super convenient if std::vector<T>::reserve *were* that function;=20
>> i.e., if we changed its semantics from *(B)* above to *(C)*
>>
>>     if capacity() < n
>>         reserve space for exactly n elements
>>     else
>>         do nothing
>>
>> However, in 17 years, this change has not happened. This suggests that=
=20
>> there's a really good reason for its not happening. What is that reason?=
=20
>> Clearly one reason would be "vendor inertia", but vendors are doing pret=
ty=20
>> well these days at keeping up with library changes, so maybe that should=
n't=20
>> be the *only* blocking reason.
>>
>
> The committee works on proposals.  I don't know if anyone has proposed=20
> this in the past.  I can see a few reasons:
>
> 1.  AFAIK implementations just pass the reserve size to the allocator=20
> anyway.
> 2.  vector<bool> cannot enforce this w/o more bookkeeping.
> 3.  It isn't all that useful w/o something like emplace_back_capped() (or=
=20
> something convoluted like a stateful allocator that allows exactly one=20
> allocation).
>

I'm aware that the Committee works on proposals; I just couldn't believe=20
that nobody had ever proposed this before, since it seems so obvious. I'd=
=20
gladly write up the relevant proposal for Kona.
1. If true, this is excellent, because it removes one possible objection to=
=20
standardizing the practice.
2. I don't see any difficulty with vector<bool> right now, but I'm not sure=
=20
how it uses its allocator. I'll investigate if I write that proposal.
3. The emplace_back_capped() etc. member functions proposed in N4416 are=20
awesome and I hope they make it in!
=20
=20

> Finally, let me open the bikeshed by suggesting that if semantics *(C)*=
=20
>> can't be given to vector::reserve(size_type n), they should at least be=
=20
>> given to a new overload vector::reserve(size_type n,=20
>> decltype(std::reserve_exactly)).  Either way, I see no reason for=20
>> N4416's proposed semantics *(A)* to ever make it into the language; they=
=20
>> just seem strictly less useful and less efficient than semantics *(C)*.
>>
>
> With (C) you cannot store non-moveable types, because the real algorithm=
=20
> is:
>
> if capacity() < n
>     reserve space for exactly n elements
>     *move_if_noexcept elements from old space to new space*
>     destroy elements in old space
>     release old space
> else
>     do nothing
>
> Various ideas are now floating around for setting exact reserve capacity.=
 =20
> We'll see if any of them survive after the presentation of this paper lat=
er=20
> this week.
>

Excellent and deadly point.
I'll float a terrible idea: You could change the key step to

    *move_if_moveable elements from old space to new space*

where *move_if_moveable* is SFINAE magic that first attempts to move, or=20
else attempts to copy, or else throws an exception. ;)

=E2=80=93Arthur

>=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5140_455899784.1430816663363
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, May 4, 2015 at 10:04:15 PM UTC-7, Nevin ":-)" L=
iber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On=
 4 May 2015 at 22:41, Arthur O'Dwyer <span dir=3D"ltr">&lt;<a href=3D"javas=
cript:" target=3D"_blank" gdf-obfuscated-mailto=3D"tyiLx2fMy7AJ" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"th=
is.href=3D'javascript:';return true;">arthur....@gmail.com</a>&gt;</span> w=
rote:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr">I've been reading Nevin Liber's N4416&nbsp;"Don=E2=80=99t Mov=
e: vector Can Have Your Non-Moveable Types Covered"<br><div><div title=3D"P=
age 1"><div><div></div></div></div></div><div><a href=3D"http://www.open-st=
d.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%=
2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4416.p=
df\46sa\75D\46sntz\0751\46usg\75AFQjCNHHJv_vt7jZk-43GIzV7AFrvVmpFA';return =
true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4416.pdf\46s=
a\75D\46sntz\0751\46usg\75AFQjCNHHJv_vt7jZk-43GIzV7AFrvVmpFA';return true;"=
>http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4416.pd=
f</a></div></div></blockquote><div><br></div><div>That paper looks familiar=
.. :-)</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>I have often wished for a member function of <font face=3D"courier ne=
w, monospace">std::vector&lt;T&gt;</font> that could give me a vector with =
capacity exactly <font face=3D"courier new, monospace">n</font>&nbsp;and no=
 more =E2=80=94 for example, if I know my vector's maximum capacity up fron=
t and I want to be economical with my memory usage; or if I'm using a user-=
defined allocator that is good at allocating blocks of one exact size and b=
ad at bigger sizes.<br></div></div></blockquote><div><br></div><div>Even if=
 you have a user-defined allocator with those properties, there really is n=
o way (other than specializing vector on the allocator type) for vector to =
communicate with the allocator to determine the optimal block size to use.&=
nbsp; The vector keeps track of capacity independent of the allocator.</div=
></div></div></div></blockquote><div><br></div><div>Right, but I'm <i>also<=
/i> the guy writing the client code that reserves the vector! So I might ha=
ve something like</div><div><a href=3D"http://melpon.org/wandbox/permlink/s=
kNNYpHPIr2v42iL">http://melpon.org/wandbox/permlink/skNNYpHPIr2v42iL</a></d=
iv><div>where I know that my allocator will return usable memory iff it is =
called with the right arguments, but I cannot rely on the std::vector imple=
mentation to actually <i>pass</i> those arguments, even when it's "obvious"=
 what should happen.</div><div><br></div><div>&nbsp;<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_q=
uote"><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
></div><div>Surely it has occurred to everybody on the Committee by now tha=
t it would be super convenient if <font face=3D"courier new, monospace">std=
::vector&lt;T&gt;::reserve</font> <b><i>were</i></b> that function; i.e., i=
f we changed its semantics from <b>(B)</b> above to <b>(C)</b><br></div><di=
v><br></div><div><font face=3D"courier new, monospace">&nbsp; &nbsp; if cap=
acity() &lt; n</font></div><div><font face=3D"courier new, monospace">&nbsp=
; &nbsp; &nbsp; &nbsp; reserve space for exactly n elements</font></div><di=
v><font face=3D"courier new, monospace">&nbsp; &nbsp; else</font></div><div=
><font face=3D"courier new, monospace">&nbsp; &nbsp; &nbsp; &nbsp; do nothi=
ng</font></div><div><br></div><div>However, in 17 years, this change has no=
t happened. This suggests that there's a really good reason for its not hap=
pening. What is that reason? Clearly one reason would be "vendor inertia", =
but vendors are doing pretty well these days at keeping up with library cha=
nges, so maybe that shouldn't be the <i>only</i> blocking reason.</div></di=
v></blockquote><div><br></div><div>The committee works on proposals.&nbsp; =
I don't know if anyone has proposed this in the past.&nbsp; I can see a few=
 reasons:</div><div><br></div><div>1.&nbsp; AFAIK implementations just pass=
 the reserve size to the allocator anyway.</div><div>2. &nbsp;vector&lt;boo=
l&gt; cannot enforce this w/o more bookkeeping.</div><div>3.&nbsp; It isn't=
 all that useful w/o something like emplace_back_capped() (or something con=
voluted like a stateful allocator that allows exactly one allocation).</div=
></div></div></div></blockquote><div><br></div><div>I'm aware that the Comm=
ittee works on proposals; I just couldn't believe that nobody had ever prop=
osed this before, since it seems so obvious. I'd gladly write up the releva=
nt proposal for Kona.</div><div>1. If true, this is excellent, because it r=
emoves one possible objection to standardizing the practice.</div><div>2. I=
 don't see any difficulty with vector&lt;bool&gt; right now, but I'm not su=
re how it uses its allocator. I'll investigate if I write that proposal.</d=
iv><div>3. The emplace_back_capped() etc. member functions proposed in N441=
6 are awesome and I hope they make it in!</div><div>&nbsp;</div><div>&nbsp;=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></=
div><div>Finally, let me open the bikeshed by suggesting that if semantics =
<b>(C)</b> can't be given to <font face=3D"courier new, monospace">vector::=
reserve(size_type n)</font>, they should at least be given to a new overloa=
d&nbsp;<font face=3D"courier new, monospace">vector::reserve(size_<wbr>type=
 n, decltype(std::reserve_exactly)<wbr>)</font>.&nbsp; Either way, I see no=
 reason for N4416's proposed semantics <b>(A)</b> to ever make it into the =
language; they just seem strictly less useful and less efficient than seman=
tics <b>(C)</b>.<br></div></div></blockquote><div><br></div><div>With (C) y=
ou cannot store non-moveable types, because the real algorithm is:</div><di=
v><br></div><div>if capacity() &lt; n</div><div>&nbsp; &nbsp; reserve space=
 for exactly n elements</div><div>&nbsp; &nbsp; <b><i>move_if_noexcept elem=
ents from old space to new space</i></b></div><div>&nbsp; &nbsp; destroy el=
ements in old space</div><div>&nbsp; &nbsp; release old space</div><div>els=
e</div><div>&nbsp; &nbsp; do nothing</div><div><br></div><div>Various ideas=
 are now floating around for setting exact reserve capacity.&nbsp; We'll se=
e if any of them survive after the presentation of this paper later this we=
ek.</div></div></div></blockquote><div><br></div><div>Excellent and deadly =
point.</div><div>I'll float a terrible idea: You could change the key step =
to</div><div><br></div><div>&nbsp; &nbsp; <b><i>move_if_moveable elements f=
rom old space to new space</i></b></div><div><br></div><div>where <i>move_i=
f_moveable</i>&nbsp;is SFINAE magic that first attempts to move, or else at=
tempts to copy, or else throws an exception. ;)</div><div><br></div><div>=
=E2=80=93Arthur</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">
</div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5140_455899784.1430816663363--
------=_Part_5139_765132860.1430816663363--

.

--Apple-Mail=_591F371A-164E-4E38-A809-EA4A7BDB389F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9305, at 11:41 AM, Arthur O'Dwyer <arthur.j.odwy=
er@gmail.com> wrote:
>=20
> I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Hav=
e Your Non-Moveable Types Covered"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
>=20
> He proposes a new member function of std::vector<T> whose name is "subjec=
t to L(E)WG bikeshedding" but tentatively proposed as std::vector<T>::reser=
ve_initially(size_type n). The semantics of this function would be (A)
>=20
>     if empty()
>         reserve space for exactly n elements
>     else
>         throw an exception

I like the idea, but it seems easier to use an adaptor which takes a non-mo=
vable type and adds a throwing move constructor:

template< typename non_movable >
struct fake_movable : non_movable {
    using non_movable::non_movable;

    [[noreturn]] fake_movable( fake_movable && )
        { throw sessile_exception(); }
};

No need to modify any containers; this gets the same results from the exist=
ing reserve and resize.

It doesn=E2=80=99t address at-most-N semantics for movable types, at least =
not while allowing insert and erase from the middle. However, I think that=
=E2=80=99s a job for allocators. There should be a concept of allocator con=
version such that std::vector<T, size_limiting_alloc< std::allocator<T> > >=
 can convert to std::vector< T, std::allocator<T> >. (I suspect that this w=
ould make allocators work much better in practice overall.)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_591F371A-164E-4E38-A809-EA4A7BDB389F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9305, at 11:41 AM, Arthur O'Dwyer &lt;<a href=3D"mailto:arthur.j.odw=
yer@gmail.com" class=3D"">arthur.j.odwyer@gmail.com</a>&gt; wrote:</div><br=
 class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" class=
=3D"">I've been reading Nevin Liber's N4416&nbsp;"Don=E2=80=99t Move: vecto=
r Can Have Your Non-Moveable Types Covered"<br class=3D""><div class=3D""><=
div class=3D"page" title=3D"Page 1"><div class=3D"layoutArea"><div class=3D=
"column"></div></div></div></div><div class=3D""><a href=3D"http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf" class=3D"">http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf</a><br class=3D""><di=
v class=3D""><br class=3D""></div></div><div class=3D"">He proposes a new m=
ember function of <font face=3D"courier new, monospace" class=3D"">std::vec=
tor&lt;T&gt;</font> whose name is "subject to L(E)WG bikeshedding" but tent=
atively proposed as <font face=3D"courier new, monospace" class=3D"">std::v=
ector&lt;T&gt;::reserve_initially(size_type n)</font>. The semantics of thi=
s function would be <b class=3D"">(A)</b></div><div class=3D""><br class=3D=
""></div><div class=3D""><font face=3D"courier new, monospace" class=3D"">&=
nbsp; &nbsp; if empty()</font></div><div class=3D""><font face=3D"courier n=
ew, monospace" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; reserve space for exa=
ctly n elements</font></div><div class=3D""><font face=3D"courier new, mono=
space" class=3D"">&nbsp; &nbsp; else</font></div><div class=3D""><font face=
=3D"courier new, monospace" class=3D"">&nbsp; &nbsp; &nbsp; &nbsp; throw an=
 exception</font></div></div></div></blockquote><div><br class=3D""></div><=
div>I like the idea, but it seems easier to use an adaptor which takes a no=
n-movable type and adds a throwing move constructor:</div><div><br class=3D=
""></div><div><font face=3D"Courier" class=3D"">template&lt; typename non_m=
ovable &gt;</font></div><div><font face=3D"Courier" class=3D"">struct fake_=
movable : non_movable {</font></div><div><font face=3D"Courier" class=3D"">=
&nbsp; &nbsp; using non_movable::non_movable;</font></div><div><font face=
=3D"Courier" class=3D""><br class=3D""></font></div><div><font face=3D"Cour=
ier" class=3D"">&nbsp; &nbsp; [[noreturn]] fake_movable( fake_movable &amp;=
&amp; )</font></div><div><font face=3D"Courier" class=3D"">&nbsp; &nbsp; &n=
bsp; &nbsp; { throw sessile_exception(); }</font></div><div><font face=3D"C=
ourier" class=3D"">};</font></div><div><br class=3D""></div><div>No need to=
 modify any containers; this gets the same results from the existing <font =
face=3D"Courier" class=3D"">reserve</font> and <font face=3D"Courier" class=
=3D"">resize</font>.</div><div><br class=3D""></div><div>It doesn=E2=80=99t=
 address at-most-N semantics for movable types, at least not while allowing=
 <font face=3D"Courier" class=3D"">insert</font> and <font face=3D"Courier"=
 class=3D"">erase</font> from the middle. However, I think that=E2=80=99s a=
 job for allocators. There should be a concept of allocator conversion such=
 that <font face=3D"Courier" class=3D"">std::vector&lt;T, size_limiting_all=
oc&lt; std::allocator&lt;T&gt; &gt; &gt;</font> can convert to <font face=
=3D"Courier" class=3D"">std::vector&lt; T, std::allocator&lt;T&gt; &gt;</fo=
nt>. (I suspect that this would make allocators work much better in practic=
e overall.)</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_591F371A-164E-4E38-A809-EA4A7BDB389F--

.

On 5 May 2015 at 04:41, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Hav=
e Your
> Non-Moveable Types Covered"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
>
>
> Surely it has occurred to everybody on the Committee by now that it would=
 be
> super convenient if std::vector<T>::reserve were that function; i.e., if =
we
> changed its semantics from (B) above to (C)
>
>     if capacity() < n
>         reserve space for exactly n elements
>     else
>         do nothing
>
> However, in 17 years, this change has not happened. This suggests that
> there's a really good reason for its not happening. What is that reason?

This is quite hard in a number of cases:

1) vector<bool> : Allocation has to take place in at least chars, and
given (basically) every modern machine has 8 bit chars, this would
require every vector<bool> stored an extra value, just to ensure they
forbid you from writing to bits of that last byte that you hadn't
reserved explicitly!

2) vector<char> and other small types: It is typical for system
allocators to have a lower bound on allocations (8 bytes is common on
a 64-bit system), and also limits for larger allocations (so above 8K,
you always get a multiple of 4K for example). Once again we might have
to store extra unnessary data, and also we would have to "throw away"
capacity which had already been allocated to a vector, just because
users didn't ask for it.

On this point 2, I am often annoyed the other way, new and malloc may
have allocated more memory than I asked for, and I would like to know
about it and use it!

Chris

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Tue, May 05, 2015 at 11:43:54AM +0100, Christopher Jefferson wrote:
> On 5 May 2015 at 04:41, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
> > I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can H=
ave Your
> > Non-Moveable Types Covered"
> > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
> >
> >
> > Surely it has occurred to everybody on the Committee by now that it wou=
ld be
> > super convenient if std::vector<T>::reserve were that function; i.e., i=
f we
> > changed its semantics from (B) above to (C)
> >
> >     if capacity() < n
> >         reserve space for exactly n elements
> >     else
> >         do nothing
> >
> > However, in 17 years, this change has not happened. This suggests that
> > there's a really good reason for its not happening. What is that reason=
?
>=20
> This is quite hard in a number of cases:
>=20
> 1) vector<bool> : Allocation has to take place in at least chars, and
> given (basically) every modern machine has 8 bit chars, this would
> require every vector<bool> stored an extra value, just to ensure they
> forbid you from writing to bits of that last byte that you hadn't
> reserved explicitly!
>=20
> 2) vector<char> and other small types: It is typical for system
> allocators to have a lower bound on allocations (8 bytes is common on
> a 64-bit system), and also limits for larger allocations (so above 8K,
> you always get a multiple of 4K for example). Once again we might have
> to store extra unnessary data, and also we would have to "throw away"
> capacity which had already been allocated to a vector, just because
> users didn't ask for it.
>=20
> On this point 2, I am often annoyed the other way, new and malloc may
> have allocated more memory than I asked for, and I would like to know
> about it and use it!

So, you would like to see something along the lines of wg14/n1085?

(http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1085.htm)

/MF

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--e89a8f50316c66e33305155d0327
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 4, 2015 at 8:41 PM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> I've been reading Nevin Liber's N4416 "Don=E2=80=99t Move: vector Can Hav=
e Your
> Non-Moveable Types Covered"
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf
>
> He proposes a new member function of std::vector<T> whose name is
> "subject to L(E)WG bikeshedding" but tentatively proposed as std::vector<=
T>::reserve_initially(size_type
> n). The semantics of this function would be *(A)*
>
>     if empty()
>         reserve space for exactly n elements
>     else
>         throw an exception
>

I like the idea, but IMO we really should not be throwing an exception
here. Just make it a precondition of the function that the vector must be
empty. If someone is catching and actually "handling" the exception,
they're just using the exception for control flow and the catch can simply
be a branch. The rationale is less than satisfying.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--e89a8f50316c66e33305155d0327
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, May 4, 2015 at 8:41 PM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr">I&#39;ve been reading Nevin Liber&#39;s N4416=C2=A0&quot;Don=E2=80=99=
t Move: vector Can Have Your Non-Moveable Types Covered&quot;<br><div><div =
title=3D"Page 1"><div><div></div></div></div></div><div><a href=3D"http://w=
ww.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf" target=3D"_blank=
">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4416.pdf</a><br>=
<div><br></div></div><div>He proposes a new member function of <font face=
=3D"courier new, monospace">std::vector&lt;T&gt;</font> whose name is &quot=
;subject to L(E)WG bikeshedding&quot; but tentatively proposed as <font fac=
e=3D"courier new, monospace">std::vector&lt;T&gt;::reserve_initially(size_t=
ype n)</font>. The semantics of this function would be <b>(A)</b></div><div=
><br></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 if empt=
y()</font></div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 reserve space for exactly n elements</font></div><div><font f=
ace=3D"courier new, monospace">=C2=A0 =C2=A0 else</font></div><div><font fa=
ce=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 throw an exceptio=
n</font></div></div></blockquote><div><br></div><div>I like the idea, but I=
MO we really should not be throwing an exception here. Just make it a preco=
ndition of the function that the vector must be empty. If someone is catchi=
ng and actually &quot;handling&quot; the exception, they&#39;re just using =
the exception for control flow and the catch can simply be a branch. The ra=
tionale is less than satisfying.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f50316c66e33305155d0327--

.

--001a11c2e4b2cdfea505155d23f3
Content-Type: text/plain; charset=UTF-8

On 5 May 2015 at 17:15, 'Matt Calabrese' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:

> I like the idea, but IMO we really should not be throwing an exception
> here. Just make it a precondition of the function that the vector must be
> empty. If someone is catching and actually "handling" the exception,
> they're just using the exception for control flow and the catch can simply
> be a branch. The rationale is less than satisfying.
>

Should LEWG go in that direction, I'm fine with it.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c2e4b2cdfea505155d23f3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">On 5 May 2015 at 17:15, &#39;Ma=
tt Calabrese&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-prop=
osals@isocpp.org</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><div>I like the idea, but IMO we really should not be =
throwing an exception here. Just make it a precondition of the function tha=
t the vector must be empty. If someone is catching and actually &quot;handl=
ing&quot; the exception, they&#39;re just using the exception for control f=
low and the catch can simply be a branch. The rationale is less than satisf=
ying.</div></div></div></div></blockquote><div><br></div><div>Should LEWG g=
o in that direction, I&#39;m fine with it.</div></div>-- <br><div class=3D"=
gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c2e4b2cdfea505155d23f3--

.

------=_Part_572_361304759.1430984359752
Content-Type: multipart/alternative;
 boundary="----=_Part_573_1512814444.1430984359752"

------=_Part_573_1512814444.1430984359752
Content-Type: text/plain; charset=UTF-8


As for the initial suggestion here, to make the new reserve_initially
function unnecessary by changing the behaviour of reserve() this is not
possible as it can't be instantiated for a non-movable type, which was the
reason to introdice the reserve_initially() function in the first place,
according to N4416.

At the same time, I don't see the need to mandate that reserve_initially()
does not allow reservation of additional elements. The programmer obviously
knows what the max limit is but it does no harm (except maybe some lost
memory) to allocate a bit more.

I think that the original intention of the definition of reserve() was to
allow implementations to "round up" the allocation to some granularity
suitable for the heap implementation, without totally loosing those bytes.
Maybe this intent is not possible to fulfil after the
introduction of allocators, due to some deficiency in the allocator API,
but I think allocators are newer than reserve()...

So we are actually have two totally separate issues, one which is addressed
by N4416 and which to keep it clean should not have changed the wording to
"exactly n elements". The other being whether the current meaning of
resize() should be changed to mandate "exactly n elements" being reserved.

I like the "core" idea of N4416 to be implemented but when it comes to the
reserve exactness I would rather see that the allocator API got fixed with
some "round up to suitable boundary" function that containers can use. This
of course solves the special issues with vector<bool> mentioned above.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_573_1512814444.1430984359752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>As for the initial suggestion here, to make the new re=
serve_initially function unnecessary by changing the behaviour of reserve()=
 this is not possible as it can't be instantiated for a non-movable type, w=
hich was the reason to introdice the reserve_initially() function in the fi=
rst place, according to N4416.<div><br></div><div>At the same time, I don't=
 see the need to mandate that reserve_initially() does not allow reservatio=
n of additional elements. The programmer obviously knows what the max limit=
 is but it does no harm (except maybe some lost memory) to allocate a bit m=
ore.</div><div><br></div><div>I think that the original intention of the de=
finition of reserve() was to allow implementations to "round up" the alloca=
tion to some granularity suitable for the heap implementation, without tota=
lly loosing those bytes. Maybe this intent is not possible to fulfil after =
the</div><div>introduction of allocators, due to some deficiency in the all=
ocator API, but I think allocators are newer than reserve()...</div><div><b=
r></div><div>So we are actually have two totally separate issues, one which=
 is addressed by N4416 and which to keep it clean should not have changed t=
he wording to "exactly n elements". The other being whether the current mea=
ning of resize() should be changed to mandate "exactly n elements" being re=
served.</div><div><br></div><div>I like the "core" idea of N4416 to be impl=
emented but when it comes to the reserve exactness I would rather see that =
the allocator API got fixed with some "round up to suitable boundary" funct=
ion that containers can use. This of course solves the special issues with =
vector&lt;bool&gt; mentioned above.</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_573_1512814444.1430984359752--
------=_Part_572_361304759.1430984359752--

.

------=_Part_896_517428791.1431003066019
Content-Type: multipart/alternative;
 boundary="----=_Part_897_1264403634.1431003066019"

------=_Part_897_1264403634.1431003066019
Content-Type: text/plain; charset=UTF-8



On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wrote:
>
>
> As for the initial suggestion here, to make the new reserve_initially
> function unnecessary by changing the behaviour of reserve() this is not
> possible as it can't be instantiated for a non-movable type, which was the
> reason to introdice the reserve_initially() function in the first place,
> according to N4416.
>
> At the same time, I don't see the need to mandate that reserve_initially()
> does not allow reservation of additional elements. The programmer obviously
> knows what the max limit is but it does no harm (except maybe some lost
> memory) to allocate a bit more.
>

For some programmers "some lost memory" is significant harm.

Besides consistency with the wording on the standard `reserve`, I don't see
anything to be gained from allowing implementations to allocate extra
elements. Remember: the whole point of `reserve_initially` is that the user
*cannot* exceed the boundary. Since you're code will never go beyond the
element count you reserve, I see no reason why an implementation would
allocate more elements than the user asked.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_897_1264403634.1431003066019
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Beng=
t Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><br>As for the initial suggestion here, to make the new reserve_initi=
ally function unnecessary by changing the behaviour of reserve() this is no=
t possible as it can't be instantiated for a non-movable type, which was th=
e reason to introdice the reserve_initially() function in the first place, =
according to N4416.<div><br></div><div>At the same time, I don't see the ne=
ed to mandate that reserve_initially() does not allow reservation of additi=
onal elements. The programmer obviously knows what the max limit is but it =
does no harm (except maybe some lost memory) to allocate a bit more.</div><=
/div></blockquote><div><br>For some programmers "some lost memory" is signi=
ficant harm.<br><br>Besides consistency with the wording on the standard `r=
eserve`, I don't see anything to be gained from allowing implementations to=
 allocate extra elements. Remember: the whole point of `reserve_initially` =
is that the user <i>cannot</i> exceed the boundary. Since you're code will =
never go beyond the element count you reserve, I see no reason why an imple=
mentation would allocate more elements than the user asked.</div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_897_1264403634.1431003066019--
------=_Part_896_517428791.1431003066019--

.

--Apple-Mail=_D76B6AD0-64BB-4B08-8590-2265E1B980AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9307, at 8:51 PM, Nicol Bolas <jmckesson@gmail.c=
om> wrote:
>=20
> Besides consistency with the wording on the standard `reserve`, I don't s=
ee anything to be gained from allowing implementations to allocate extra el=
ements.

For std::string, it enables the SSO. Perhaps the generic description should=
 be constrained a bit for std::vector, but that=E2=80=99s all.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_D76B6AD0-64BB-4B08-8590-2265E1B980AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9307, at 8:51 PM, Nicol Bolas &lt;<a href=3D"mailto:jmckesson@gmail.=
com" class=3D"">jmckesson@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-=
interchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Besides co=
nsistency with the wording on the standard `reserve`, I don't see anything =
to be gained from allowing implementations to allocate extra elements.</div=
></div></blockquote><div><br class=3D""></div><div>For <font face=3D"Courie=
r" class=3D"">std::string</font>, it enables the SSO. Perhaps the generic d=
escription should be constrained a bit for std::vector, but that=E2=80=99s =
all.</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_D76B6AD0-64BB-4B08-8590-2265E1B980AF--

.

--Apple-Mail=_3F2048F4-EEF6-43BD-A682-DCD31CFCAC44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9305=E2=80=9307, at 8:57 PM, David Krauss <potswa@mac.com> =
wrote:
>=20
> For std::string, it enables the SSO. Perhaps the generic description shou=
ld be constrained a bit for std::vector, but that=E2=80=99s all.

Oh, it=E2=80=99s not as generic as I thought. There=E2=80=99s no std::deque=
::reserve, only vector and string (and vector<bool>, which might as well ha=
ve its own exception to any such rule). The allowance for vector might have=
 been written when there was such a thing as a small-vector optimization, a=
nd never revised since.

Maybe a defect report is worth a shot=E2=80=A6

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_3F2048F4-EEF6-43BD-A682-DCD31CFCAC44
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9305=
=E2=80=9307, at 8:57 PM, David Krauss &lt;<a href=3D"mailto:potswa@mac.com"=
 class=3D"">potswa@mac.com</a>&gt; wrote:</div><br class=3D"Apple-interchan=
ge-newline"><div class=3D""><meta http-equiv=3D"Content-Type" content=3D"te=
xt/html charset=3Dutf-8" class=3D""><div style=3D"word-wrap: break-word; -w=
ebkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=3D"">=
For <font face=3D"Courier" class=3D"">std::string</font>, it enables the SS=
O. Perhaps the generic description should be constrained a bit for std::vec=
tor, but that=E2=80=99s all.</div></div></blockquote></div><br class=3D""><=
div class=3D"">Oh, it=E2=80=99s not as generic as I thought. There=E2=80=99=
s no <font face=3D"Courier" class=3D"">std::deque::reserve</font>, only <fo=
nt face=3D"Courier" class=3D"">vector</font> and <font face=3D"Courier" cla=
ss=3D"">string</font>&nbsp;(and <font face=3D"Courier" class=3D"">vector&lt=
;bool&gt;</font>, which might as well have its own exception to any such ru=
le). The allowance for vector might have been written when there was such a=
 thing as a small-vector optimization, and never revised since.</div><div c=
lass=3D""><br class=3D""></div><div class=3D"">Maybe a defect report is wor=
th a shot=E2=80=A6</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3F2048F4-EEF6-43BD-A682-DCD31CFCAC44--

.

On 2015-05-07 14:51, Nicol Bolas wrote:
>
>
> On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wrote:
>
>
>     As for the initial suggestion here, to make the new
>     reserve_initially function unnecessary by changing the behaviour of
>     reserve() this is not possible as it can't be instantiated for a
>     non-movable type, which was the reason to introdice the
>     reserve_initially() function in the first place, according to N4416.
>
>     At the same time, I don't see the need to mandate that
>     reserve_initially() does not allow reservation of additional
>     elements. The programmer obviously knows what the max limit is but
>     it does no harm (except maybe some lost memory) to allocate a bit more.
>
>
> For some programmers "some lost memory" is significant harm.
>
> Besides consistency with the wording on the standard `reserve`, I don't
> see anything to be gained from allowing implementations to allocate
> extra elements. Remember: the whole point of `reserve_initially` is that
> the user /cannot/ exceed the boundary. Since you're code will never go
> beyond the element count you reserve, I see no reason why an
> implementation would allocate more elements than the user asked.
>

Possibly because the user asked for too few elements.  :-)

What should an implementation do with a vector<char> when a user asks
for one element only? Should it be non-conforming to actually allocate 4
or 8 bytes?


Bo Persso


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_884_1840650858.1431023949563
Content-Type: multipart/alternative;
 boundary="----=_Part_885_1317035371.1431023949563"

------=_Part_885_1317035371.1431023949563
Content-Type: text/plain; charset=UTF-8



On Thursday, May 7, 2015 at 1:05:50 PM UTC-4, Bo Persson wrote:
>
> On 2015-05-07 14:51, Nicol Bolas wrote:
> >
> >
> > On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wrote:
> >
> >
> >     As for the initial suggestion here, to make the new
> >     reserve_initially function unnecessary by changing the behaviour of
> >     reserve() this is not possible as it can't be instantiated for a
> >     non-movable type, which was the reason to introdice the
> >     reserve_initially() function in the first place, according to N4416.
> >
> >     At the same time, I don't see the need to mandate that
> >     reserve_initially() does not allow reservation of additional
> >     elements. The programmer obviously knows what the max limit is but
> >     it does no harm (except maybe some lost memory) to allocate a bit
> more.
> >
> >
> > For some programmers "some lost memory" is significant harm.
> >
> > Besides consistency with the wording on the standard `reserve`, I don't
> > see anything to be gained from allowing implementations to allocate
> > extra elements. Remember: the whole point of `reserve_initially` is that
> > the user /cannot/ exceed the boundary. Since you're code will never go
> > beyond the element count you reserve, I see no reason why an
> > implementation would allocate more elements than the user asked.
> >
>
> Possibly because the user asked for too few elements.  :-)
>
> What should an implementation do with a vector<char> when a user asks
> for one element only? Should it be non-conforming to actually allocate 4
> or 8 bytes?
>
>
> Bo Persso
>

You're thinking in terms of what the allocator does. I'm thinking in terms
of what the *vector* does.

The vector tells the allocator that it wants enough memory for X objects.
What the allocator has to do to get that is really none of the vector's
business.

If you take a std::vector<char> and have it reserve_initially space for
only 1 element, then vector::capacity will return *one.* The result of
performing emplace_back_capped more than one will be an exception. It
doesn't matter if the allocator returned a valid block containing 1 char or
50; as far as the vector is concerned, there is exactly and only enough
space for 1 char.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_885_1317035371.1431023949563
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, May 7, 2015 at 1:05:50 PM UTC-4, Bo P=
ersson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-05-07 14:=
51, Nicol Bolas wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Thursday, May 7, 2015 at 3:39:19 AM UTC-4, Bengt Gustafsson wro=
te:
<br>&gt;
<br>&gt;
<br>&gt; &nbsp; &nbsp; As for the initial suggestion here, to make the new
<br>&gt; &nbsp; &nbsp; reserve_initially function unnecessary by changing t=
he behaviour of
<br>&gt; &nbsp; &nbsp; reserve() this is not possible as it can't be instan=
tiated for a
<br>&gt; &nbsp; &nbsp; non-movable type, which was the reason to introdice =
the
<br>&gt; &nbsp; &nbsp; reserve_initially() function in the first place, acc=
ording to N4416.
<br>&gt;
<br>&gt; &nbsp; &nbsp; At the same time, I don't see the need to mandate th=
at
<br>&gt; &nbsp; &nbsp; reserve_initially() does not allow reservation of ad=
ditional
<br>&gt; &nbsp; &nbsp; elements. The programmer obviously knows what the ma=
x limit is but
<br>&gt; &nbsp; &nbsp; it does no harm (except maybe some lost memory) to a=
llocate a bit more.
<br>&gt;
<br>&gt;
<br>&gt; For some programmers "some lost memory" is significant harm.
<br>&gt;
<br>&gt; Besides consistency with the wording on the standard `reserve`, I =
don't
<br>&gt; see anything to be gained from allowing implementations to allocat=
e
<br>&gt; extra elements. Remember: the whole point of `reserve_initially` i=
s that
<br>&gt; the user /cannot/ exceed the boundary. Since you're code will neve=
r go
<br>&gt; beyond the element count you reserve, I see no reason why an
<br>&gt; implementation would allocate more elements than the user asked.
<br>&gt;
<br>
<br>Possibly because the user asked for too few elements. &nbsp;:-)
<br>
<br>What should an implementation do with a vector&lt;char&gt; when a user =
asks=20
<br>for one element only? Should it be non-conforming to actually allocate =
4=20
<br>or 8 bytes?
<br>
<br>
<br>Bo Persso<br></blockquote><div><br>You're thinking in terms of what the=
 allocator does. I'm thinking in terms of what the <i>vector</i> does.<br><=
br>The vector tells the allocator that it wants enough memory for X objects=
.. What the allocator has to do to get that is really none of the vector's b=
usiness.<br><br>If you take a std::vector&lt;char&gt; and have it reserve_i=
nitially space for only 1 element, then vector::capacity will return <i>one=
..</i> The result of performing emplace_back_capped more than one will be an=
 exception. It doesn't matter if the allocator returned a valid block conta=
ining 1 char or 50; as far as the vector is concerned, there is exactly and=
 only enough space for 1 char.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_885_1317035371.1431023949563--
------=_Part_884_1840650858.1431023949563--

.