--089e0160b5e21bdae8050f0dd802
Content-Type: text/plain; charset=UTF-8

While reading N4359 it occured to me that while a release()  operation
would be useful for the same reasons than unique_ptr's release() operation
is useful, vector do not have a way to acquire ownership
of a manually provided array of data.

That is, if an array is released from a vector, it cannot be inserted in
another vector
without copying it.

It seems to me that this is a missed opportunity in cases where
you get a dynamically allocated array from one API and you want
to manage it in as a vector in your code. That is, you want to keep the
growing behaviour of vector (otherwise you would use a unique_pointer with
array)
but you also want to avoid an array copy and delete when getting an array
from
a C api for example.

Ownership acquisition would be implemented as a constructor (maybe tagged
by a parametter to help clarity)
and an member function.
I exclude assignment operator overloads because there is a need to provide
the size
and and maybe a (polymophic?) allocator to the vector.

Of course this ownership acquisition would be less safe than the current
copy behaviour
but it would be useful for high performance applications in contexts
described as before.


Any thoughts on this?

--

---
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/.

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

<div dir=3D"ltr">While reading N4359 it occured to me that while a release(=
) =C2=A0operation<div>would be useful for the same reasons than unique_ptr&=
#39;s release() operation</div><div>is useful, vector do not have a way to =
acquire ownership</div><div>of a manually provided array of data.</div><div=
><br></div><div>That is, if an array is released from a vector, it cannot b=
e inserted in another vector</div><div>without copying it.</div><div><br></=
div><div>It seems to me that this is a missed opportunity in cases where=C2=
=A0</div><div>you get a dynamically allocated array from one API and you wa=
nt=C2=A0</div><div>to manage it in as a vector in your code. That is, you w=
ant to keep the</div><div>growing behaviour of vector (otherwise you would =
use a unique_pointer with array)</div><div>but you also want to avoid an ar=
ray copy and delete when getting an array from</div><div>a C api for exampl=
e.</div><div><br></div><div>Ownership acquisition would be implemented as a=
 constructor (maybe tagged by a parametter to help clarity)</div><div>and a=
n member function.<br></div><div>I exclude assignment operator overloads be=
cause there is a need to provide the size=C2=A0</div><div>and and maybe a (=
polymophic?) allocator to the vector.</div><div><br></div><div>Of course th=
is ownership acquisition would be less safe than the current copy behaviour=
</div><div>but it would be useful for high performance applications in cont=
exts described as before.</div><div><br></div><div><br></div><div>Any thoug=
hts on this?</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 />

--089e0160b5e21bdae8050f0dd802--

.