------=_Part_440_343734533.1410506723308
Content-Type: text/plain; charset=UTF-8

Hi,

I noticed today after using allocators for some stuff how easy it is to
incorporate custom allocators with shared_ptr but what a significant rise
in difficulty it is to do the same with unique_ptr. I think this is quite a
shame as using allocators correctly and exception safe is not exactly
trivial and involves quite an amount of boilerplate.

The basic idea here is to provide allocate_unique<T>(Allocator&&, Args&&...).
The returned type is something like unique_ptr<T,
allocator_delete<ReboundAllocator>> where allocator_delete<ReboundAllocator> is
a new standard deleter storing a copy of the allocator rebound for T and
its operator() performs the destruction and deletion using said allocator.
Now, allocate_shared is an optimization and originated from the desire to
avoid an extra allocation. This optimization is completely irrelevant for
unique_ptr, however it would make the usage of custom allocators vastly
more user friendly (and I know people who get very uncomfortable when
having to use allocators for object creation/deletion).

I scribbled together a sample implementation for allocate_unique and
allocator_delete but I'd like to hear opinions first before delving into
implementation details. Do you think this use case is frequent enough to
justify addition to the standard library? Is there maybe a better way to
simplify the steps involved in correctly using custom allocators when
shared_ptr is not desired?

Miro

--

---
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_440_343734533.1410506723308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<div><br></div><div>I noticed today after using allocat=
ors for some stuff how easy it is to incorporate custom allocators with <fo=
nt face=3D"courier new, monospace">shared_ptr</font>&nbsp;but what a signif=
icant rise in difficulty it is to do the same with <font face=3D"courier ne=
w, monospace">unique_ptr.</font>&nbsp;I think this is quite a shame as usin=
g allocators correctly and exception safe is not exactly trivial and involv=
es quite an amount of boilerplate.</div><div><br></div><div>The basic idea =
here is to provide&nbsp;<font face=3D"courier new, monospace">allocate_uniq=
ue&lt;T&gt;(Allocator&amp;&amp;, Args&amp;&amp;...)</font><font face=3D"ari=
al, sans-serif">. </font>The returned type is something like <font face=3D"=
courier new, monospace">unique_ptr&lt;T, allocator_delete&lt;ReboundAllocat=
or&gt;&gt;</font><font face=3D"arial, sans-serif">&nbsp;where&nbsp;</font><=
span style=3D"font-family: 'courier new', monospace;">allocator_delete&lt;R=
eboundAllocator&gt;</span><font face=3D"arial, sans-serif">&nbsp;is a new s=
tandard deleter storing a copy of the allocator rebound for </font><font fa=
ce=3D"courier new, monospace">T</font><font face=3D"arial, sans-serif"> and=
 its </font><font face=3D"courier new, monospace">operator()</font><font fa=
ce=3D"arial, sans-serif"> performs the destruction and deletion using said =
allocator.&nbsp;</font>Now,&nbsp;<font face=3D"courier new, monospace">allo=
cate_shared</font>&nbsp;is an optimization and originated from the desire t=
o avoid an extra allocation. This optimization is completely irrelevant for=
 <font face=3D"courier new, monospace">unique_ptr</font>, however it would =
make the usage of custom allocators vastly more user friendly (and I know p=
eople who get very uncomfortable when having to use allocators for object c=
reation/deletion).</div><div><font face=3D"arial, sans-serif"><br></font></=
div><div><font face=3D"arial, sans-serif">I scribbled together a sample imp=
lementation for&nbsp;</font><font face=3D"courier new, monospace">allocate_=
unique</font><font face=3D"arial, sans-serif"> and </font><font face=3D"cou=
rier new, monospace">allocator_delete</font><font face=3D"arial, sans-serif=
"> but I'd like to hear opinions first before delving into implementation d=
etails. Do you think this use case is frequent enough to justify addition t=
o the standard library? Is there maybe a better way to simplify the steps i=
nvolved in correctly using custom allocators when </font><font face=3D"cour=
ier new, monospace">shared_ptr</font><font face=3D"arial, sans-serif"> is n=
ot desired?</font></div><div><font face=3D"arial, sans-serif"><br></font></=
div><div><font face=3D"arial, sans-serif">Miro</font></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_440_343734533.1410506723308--

.

--Apple-Mail=_09F77CBA-D366-4275-8D89-9A3B5C8CB644
Content-Type: text/plain; charset=ISO-8859-1


On 2014-09-12, at 3:25 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

> Do you think this use case is frequent enough to justify addition to the standard library? Is there maybe a better way to simplify the steps involved in correctly using custom allocators when shared_ptr is not desired?

Yes, I've also noticed. It's an odd omission. allocate_unique is just as necessary as make_unique, not because of optimization but exception safety. Note that make_unique was new in C++14; it was added after the rest of the smart pointer facilities.

--

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

--Apple-Mail=_09F77CBA-D366-4275-8D89-9A3B5C8CB644
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;09&ndash;12, at 3:25 PM, Miro Knejp &lt;<a href=3D"mailto:miro.knejp@=
gmail.com">miro.knejp@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inte=
rchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div><font face=
=3D"arial, sans-serif">Do you think this use case is frequent enough to jus=
tify addition to the standard library? Is there maybe a better way to simpl=
ify the steps involved in correctly using custom allocators when </font><fo=
nt face=3D"courier new, monospace">shared_ptr</font><font face=3D"arial, sa=
ns-serif"> is not desired?</font></div></div></blockquote><div><br></div><d=
iv>Yes, I&rsquo;ve also noticed. It&rsquo;s an odd omission. <font face=3D"=
Courier">allocate_unique</font> is just as necessary as <font face=3D"Couri=
er">make_unique</font>, not because of optimization but exception safety. N=
ote that <font face=3D"Courier">make_unique</font> was new in C++14; it was=
 added after the rest of the smart pointer facilities.</div></div><br></bod=
y></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=_09F77CBA-D366-4275-8D89-9A3B5C8CB644--

.