--047d7bdc7d52d2b31004f1175cd9
Content-Type: text/plain; charset=ISO-8859-1

HI Andrew,

With an API like that, there are numerous ways you could handle it, but
> to keep it simple I'd just do something like this:
>
> IplImage* pImage = cvCreateImage(size, depth, channels);
> auto releaseImage = make_scoped_resource(cvReleaseImage, &pImage, nullptr);
>
> Then the code can go on to access the pImage knowing it's clean-up is
> managed by releaseImage.  For me it's about managing the lifetime up
> front so that you don't need to worry about leaks on exception unwind or
> other exit scenarios.  The fact that I have a named variable that is used
> for nothing more than to ensure clean-up doesn't bother me.
>

Yes, that's what I usually do.
I've used shared_ptr<> with a custom deleters, SCOPE_EXIT or STLSoft's
scoped_handle (among other similar solutions).
However, as you guessed I like the automatic conversion so there are fewer
variables in the local name scope and the code is cleaner, without a bunch
or auto_releaser variables.


> If you really cared though you could do as I think you were asking:
>
> auto pImage = make_scoped_resource([](IplImage* pImg) ->void
> {
>     cvReleaseImage(&pImg);
> }, cvCreateImage(size, depth, channels), nullptr);
>
> This would allow you to still utilize pImage in APIs that need aIplImage*, and
> to test it for validity, etc.  And the nullptr check is built-in so that
> you don't need in the lambda.
>

That's how my deleters look. I guess that as good solution as any.

Just a thought, I have seen many APIs that want a reference, do you think
it would make sense to have some automatic detection of this case?
In the case that the deleter function requires a ** have it automatically
pass the address of the pointer?
Or maybe have some ready-made adapter a-la std::ref()?

In any case, I hope this passes.

Warm regards,
Adi

--

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

--047d7bdc7d52d2b31004f1175cd9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">HI Andrew,<div><br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>With =
an API like that, there are numerous ways you could handle it, but to=A0kee=
p it simple I&#39;d just do something like this:</div>

<div><br></div><div><font face=3D"courier new,monospace">IplImage* pImage =
=3D</font> <tt>cvCreateImage(size, depth, channels);</tt></div><div><tt>aut=
o releaseImage =3D make_scoped_resource(cvReleaseImage, &amp;pImage, nullpt=
r);</tt></div>

<div><tt><br></tt></div><div><tt><font face=3D"arial,sans-serif">Then the c=
ode can go on to access the</font> pImage <font face=3D"arial,sans-serif">k=
nowing it&#39;s clean-up is managed by</font> releaseImage.<font face=3D"ar=
ial,sans-serif">=A0 For me it&#39;s about managing the lifetime up front so=
 that you don&#39;t need to worry about leaks on exception unwind or other =
exit scenarios.=A0 The fact that I have a named variable that is used for n=
othing more than to ensure clean-up doesn&#39;t bother me.</font></tt></div=
>

</div></blockquote><div><br></div><div>Yes, that&#39;s what I usually do.=
=A0</div><div>I&#39;ve used shared_ptr&lt;&gt; with a custom deleters, SCOP=
E_EXIT or STLSoft&#39;s scoped_handle (among other similar solutions).=A0</=
div>

<div>However, as you guessed I like the automatic conversion so there are f=
ewer variables in the local name scope and the code is cleaner, without a b=
unch or auto_releaser variables.</div><div>=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex">

<div dir=3D"ltr"><div><span style=3D"font-family:arial,sans-serif">If you r=
eally cared though you could do as I think you were asking:</span><br></div=
><div><tt><br></tt></div><div><tt>auto pImage =3D make_scoped_resource([](I=
plImage* pImg) -&gt;void</tt></div>

<div><tt>{</tt></div><div><tt>=A0=A0=A0 cvReleaseImage(&amp;pImg);</tt></di=
v><div><tt>}, cvCreateImage(size, depth, channels), nullptr);</tt></div><di=
v><tt><br></tt></div><div><tt><font face=3D"arial,sans-serif">This would al=
low you to still utilize</font> pImage <font face=3D"arial,sans-serif">in A=
PIs that need a</font> IplImage*, <font face=3D"arial,sans-serif">and to te=
st it for validity, etc.</font>=A0 <font face=3D"arial,sans-serif">And the<=
/font> nullptr <font face=3D"arial,sans-serif">check is built-in so that yo=
u don&#39;t need in the lambda.</font></tt></div>

</div></blockquote><div><br></div><div>That&#39;s how my deleters look. I g=
uess that as good solution as any.</div><div><br></div><div>Just a thought,=
 I have seen many APIs that want a reference, do you think it would make se=
nse to have some automatic detection of this case?</div>

<div>In the case that the deleter function requires a ** have it automatica=
lly pass the address of the pointer?</div><div>Or maybe have some ready-mad=
e adapter a-la std::ref()?</div><div><br></div><div>In any case, I hope thi=
s passes.</div>

<div><br></div><div>Warm regards,</div><div>Adi</div></div></div></div></di=
v>

<p></p>

-- <br />
&nbsp;<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />

--047d7bdc7d52d2b31004f1175cd9--

.

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

A scope_guard *is* essentially a resource manager but with convenient
(optional) early release semantics.
These extra semantics presumably might have extra cost and it provides a
different type of concept for different types of resource (or operation)
management.
That's not to say that one cannot be implemented on top of the other.

 I am not sure I see the connection to std::uncaught_exceptions.


On Thu, Nov 27, 2014 at 10:26 AM, <german.gomez@personifyinc.com> wrote:

> I wonder if we would need this anymore in the language, compared to a more
> general
> scope_guard with failure/exit. std::uncaught_exceptions was recently
> approved into the standard.
>
>
> On Sunday, January 26, 2014 2:16:13 PM UTC+7, Adi Shavit wrote:
>>
>> Hi,
>>
>>   I've been longing for this for a long time. I look forward to seeing
>> something like this in the standard.
>>
>> How would scoped_resource handle release functions that take the
>> address-of the resource?
>> I've seen many APIs that take a ** so they can set the ptr to NULL.
>> For example see this: http://docs.opencv.org/modules/core/doc/old_basic_
>> structures.html?highlight=cvreleaseimage#releaseimage
>>
>> I guess you could do it with a lambda but then you actually need a way to
>> reference the resource itself to take its address.
>> Also, writing this lambda every time is tedious and error prone as this
>> is quite a common API approach.
>>
>> Adi
>>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--

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

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

<div dir=3D"ltr">A scope_guard <i>is</i> essentially a resource manager but=
 with convenient (optional) early release semantics.<div>These extra semant=
ics presumably might have extra cost and it provides a different type of co=
ncept for different types of resource (or operation) management.</div><div>=
That&#39;s not to say that one cannot be implemented on top of the other.</=
div><div><br></div><div>=C2=A0I am not sure I see the connection to std::un=
caught_exceptions.</div><div><br><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Thu, Nov 27, 2014 at 10:26 AM,  <span dir=3D"ltr">&lt;<=
a href=3D"mailto:german.gomez@personifyinc.com" target=3D"_blank">german.go=
mez@personifyinc.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-co=
lor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"=
ltr">I wonder if we would need this anymore in the language, compared to a =
more general<div>scope_guard with failure/exit. std::uncaught_exceptions wa=
s recently approved into the standard.<div><div class=3D"h5"><br><br>On Sun=
day, January 26, 2014 2:16:13 PM UTC+7, Adi Shavit wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>=C2=A0 I&#39;ve been lon=
ging for this for a long time. I look forward to seeing something like this=
 in the standard.</div><div><br></div><div>How would <font face=3D"courier =
new, monospace">scoped_resource</font> handle release functions that take t=
he address-of the resource?</div><div>I&#39;ve seen many APIs that take a <=
font face=3D"courier new, monospace">**</font> so they can set the ptr to <=
font face=3D"courier new, monospace">NULL</font>.=C2=A0</div><div>For examp=
le see this: <a href=3D"http://docs.opencv.org/modules/core/doc/old_basic_s=
tructures.html?highlight=3Dcvreleaseimage#releaseimage" target=3D"_blank">h=
ttp://docs.opencv.org/<u></u>modules/core/doc/old_basic_<u></u>structures.h=
tml?highlight=3D<u></u>cvreleaseimage#releaseimage</a></div><div><br></div>=
<div>I guess you could do it with a lambda but then you actually need a way=
 to reference the resource itself to take its address.</div><div>Also, writ=
ing this lambda every time is tedious and error prone as this is quite a co=
mmon API approach.</div><div><br></div><div>Adi</div></div></blockquote></d=
iv></div></div></div><div class=3D""><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></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 />

--001a11c264f25405f80508d40c95--

.

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

On Thu, Nov 27, 2014 at 2:26 AM, <german.gomez@personifyinc.com> wrote:

> I wonder if we would need this anymore in the language, compared to a more
> general
> scope_guard with failure/exit. std::uncaught_exceptions was recently
> approved into the standard.
>

We need it every bit as much as we need unique_ptr.  Exception unwinding is
only part of the issue.  The other part is having a means of
planning/stating/managing resource lifetime at the time the resource is
created.

Unless I'm missing something, I don't believe that uncaught_exception is
going to help in the case where your code is called by a 3rd party API
(etc.) that has a try/catch.  If your code isn't using RAII or its own
try/catch blocks, but calls something else (another func/method in the same
3rd party API for example) that throws an exception it can unwind right
past your code and  your resources will still leak.

-Andrew

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Nov 27, 2014 at 2:26 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
erman.gomez@personifyinc.com" target=3D"_blank">german.gomez@personifyinc.c=
om</a>&gt;</span> wrote:<br><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"=
>I wonder if we would need this anymore in the language, compared to a more=
 general<div>scope_guard with failure/exit. std::uncaught_exceptions was re=
cently approved into the standard.<div><div class=3D"h5"></div></div></div>=
</div></blockquote></div><br>We need it every bit as much as we need unique=
_ptr.=C2=A0 Exception unwinding is only part of the issue.=C2=A0 The other =
part is having a means of planning/stating/managing resource lifetime at th=
e time the resource is created.<br><br></div><div class=3D"gmail_extra">Unl=
ess I&#39;m missing something, I don&#39;t believe that uncaught_exception =
is going to help in the case where your code is called by a 3rd party API (=
etc.) that has a try/catch.=C2=A0 If your code isn&#39;t using RAII or its =
own try/catch blocks, but calls something else (another func/method in the =
same 3rd party API for example) that throws an exception it can unwind righ=
t past your code and=C2=A0 your resources will still leak.<br><br></div><di=
v class=3D"gmail_extra">-Andrew<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 />

--001a11c0d406d7b2fb0508e16521--

.

--Apple-Mail=_E9C7384E-FBB3-453D-B6E1-2C3B64BEC020
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9328, at 9:44 AM, Andrew Sandoval <sandoval@netway=
sglobal.com> wrote:

> Unless I'm missing something, I don't believe that uncaught_exception is =
going to help in the case where your code is called by a 3rd party API (etc=
..) that has a try/catch.  If your code isn't using RAII or its own try/catc=
h blocks, but calls something else (another func/method in the same 3rd par=
ty API for example) that throws an exception it can unwind right past your =
code and  your resources will still leak.

The intent of uncaught_exception(s) to be called from a destructor (perhaps=
 indirectly) and indicate whether an immediate throw would be sudden death.=
 This allows you to split destructors into success and failure modes, such =
as cleanup code installed into a scope guard or generic resource template.

Such complexity is probably better placed in an explicitly-defined class, n=
ot scoped_resource. For that matter, I=E2=80=99d probably always define a c=
lass in favor of calling make_scoped_resource.

--=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=_E9C7384E-FBB3-453D-B6E1-2C3B64BEC020
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=
=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=
=E2=80=9311=E2=80=9328, at 9:44 AM, Andrew Sandoval &lt;<a href=3D"mailto:s=
andoval@netwaysglobal.com">sandoval@netwaysglobal.com</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=
=3D"ltr"><div class=3D"gmail_extra">Unless I'm missing something, I don't b=
elieve that uncaught_exception is going to help in the case where your code=
 is called by a 3rd party API (etc.) that has a try/catch.&nbsp; If your co=
de isn't using RAII or its own try/catch blocks, but calls something else (=
another func/method in the same 3rd party API for example) that throws an e=
xception it can unwind right past your code and&nbsp; your resources will s=
till leak.</div></div></blockquote><div><br></div><div>The intent of uncaug=
ht_exception(s) to be called from a destructor (perhaps indirectly) and ind=
icate whether an immediate throw would be sudden death. This allows you to =
split destructors into success and failure modes, such as cleanup code inst=
alled into a scope guard or generic resource template.</div><div><br></div>=
<div>Such complexity is probably better placed in an explicitly-defined cla=
ss, not <font face=3D"Courier">scoped_resource</font>. For that matter, I=
=E2=80=99d probably <i>always</i> define a class in favor of calling <font =
face=3D"Courier">make_scoped_resource</font>.</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=_E9C7384E-FBB3-453D-B6E1-2C3B64BEC020--

.

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

On Thu, Nov 27, 2014 at 8:35 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9311=E2=80=9328, at 9:44 AM, Andrew Sandoval <sandoval@netw=
aysglobal.com>
> wrote:
>
> Unless I'm missing something, I don't believe that uncaught_exception is
> going to help in the case where your code is called by a 3rd party API
> (etc.) that has a try/catch.  If your code isn't using RAII or its own
> try/catch blocks, but calls something else (another func/method in the sa=
me
> 3rd party API for example) that throws an exception it can unwind right
> past your code and  your resources will still leak.
>
>
> The intent of uncaught_exception(s) to be called from a destructor
> (perhaps indirectly) and indicate whether an immediate throw would be
> sudden death. This allows you to split destructors into success and failu=
re
> modes, such as cleanup code installed into a scope guard or generic
> resource template.
>
> Such complexity is probably better placed in an explicitly-defined class,
> not scoped_resource. For that matter, I=E2=80=99d probably *always* defin=
e a
> class in favor of calling make_scoped_resource.
>
> --
>
Yes, I understand that -- and if you want to encapsulate everything that is
fine, but we don't require writing a class to encapsulate every kind of
pointer -- the standard library provides unique_ptr and shared_ptr.
scope_exit and unique_resource are similar.  They may not be for everyone
-- definitely not for every RAII need, but extremely useful nonetheless.

I'm not negating the value of uncaught_exception, just suggesting that it
can't replace the classes proposed in N4189.

I could give examples, but rather than do that, I would just ask you to
think outside of the context you are accustomed to, and realize that there
are many environments and situations where these classes will benefit the
code base substantially, even if you can't see it being useful to you.
There are times when exception are forbidden because of where the code will
run.  There are times when customer requirements or special cases limit the
size of compiled code, etc., etc.  In each case there are parts of the
standard library that apply themselves better than others.  More useful
classes like these is always a good thing, even if some people will never
use them or understand the benefit they provide.

I use a relatively small portion of the standard library on a regular
basis, but when I'm working in a new environment or with different ground
rules - or solving a unique problem, I'm really glad to know that there are
many things out there that I can utilize when the fit is right.

-Andrew

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

--001a1139b1d23b7be00508f914e2
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 T=
hu, Nov 27, 2014 at 8:35 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word=
"><br><div><span class=3D""><div>On 2014=E2=80=9311=E2=80=9328, at 9:44 AM,=
 Andrew Sandoval &lt;<a href=3D"mailto:sandoval@netwaysglobal.com" target=
=3D"_blank">sandoval@netwaysglobal.com</a>&gt; wrote:</div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">Unless I&#39;m mi=
ssing something, I don&#39;t believe that uncaught_exception is going to he=
lp in the case where your code is called by a 3rd party API (etc.) that has=
 a try/catch.=C2=A0 If your code isn&#39;t using RAII or its own try/catch =
blocks, but calls something else (another func/method in the same 3rd party=
 API for example) that throws an exception it can unwind right past your co=
de and=C2=A0 your resources will still leak.</div></div></blockquote><div><=
br></div></span><div>The intent of uncaught_exception(s) to be called from =
a destructor (perhaps indirectly) and indicate whether an immediate throw w=
ould be sudden death. This allows you to split destructors into success and=
 failure modes, such as cleanup code installed into a scope guard or generi=
c resource template.</div><div><br></div><div>Such complexity is probably b=
etter placed in an explicitly-defined class, not <font face=3D"Courier">sco=
ped_resource</font>. For that matter, I=E2=80=99d probably <i>always</i> de=
fine a class in favor of calling <font face=3D"Courier">make_scoped_resourc=
e</font>.</div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- </div></div></blockquote></div>Yes, I understand that -- and if you want=
 to encapsulate everything that is fine, but we don&#39;t require writing a=
 class to encapsulate every kind of pointer -- the standard library provide=
s unique_ptr and shared_ptr.=C2=A0 scope_exit and unique_resource are simil=
ar.=C2=A0 They may not be for everyone -- definitely not for every RAII nee=
d, but extremely useful nonetheless.<br><br></div><div class=3D"gmail_extra=
">I&#39;m not negating the value of uncaught_exception, just suggesting tha=
t it can&#39;t replace the classes proposed in N4189.<br><br></div><div cla=
ss=3D"gmail_extra">I could give examples, but rather than do that, I would =
just ask you to think outside of the context you are accustomed to, and rea=
lize that there are many environments and situations where these classes wi=
ll benefit the code base substantially, even if you can&#39;t see it being =
useful to you.=C2=A0 There are times when exception are forbidden because o=
f where the code will run.=C2=A0 There are times when customer requirements=
 or special cases limit the size of compiled code, etc., etc.=C2=A0 In each=
 case there are parts of the standard library that apply themselves better =
than others.=C2=A0 More useful classes like these is always a good thing, e=
ven if some people will never use them or understand the benefit they provi=
de.<br><br>I use a relatively small portion of the standard library on a re=
gular basis, but when I&#39;m working in a new environment or with differen=
t ground rules - or solving a unique problem, I&#39;m really glad to know t=
hat there are many things out there that I can utilize when the fit is righ=
t.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">-An=
drew<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 />

--001a1139b1d23b7be00508f914e2--

.

--Apple-Mail=_F9A291C0-E114-4F6B-87C0-A18BDD1D0C66
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


On 2014=E2=80=9311=E2=80=9329, at 1:59 PM, Andrew Sandoval <sandoval@netway=
sglobal.com> wrote:

> I'm not negating the value of uncaught_exception, just suggesting that it=
 can't replace the classes proposed in N4189.

uncaught_exceptions makes destructors more powerful and N4189 provides new =
ways to define destructors. So, they=E2=80=99re complementary.

> I could give examples, but rather than do that, I would just ask you to t=
hink outside of the context you are accustomed to, and realize that there a=
re many environments and situations where these classes will benefit the co=
de base substantially, even if you can't see it being useful to you.=20

To me, the comparison is between an explicitly-defined destructor in an exp=
licitly-defined class, and the convenience templates in N4189. They are for=
 convenience; there=E2=80=99s no added capability.

The concern is that the convenience of unique_resource is negligible becaus=
e the reader needs to mentally model how it captures state and generates de=
struction semantics, when the destructor would have been easy to write and =
much easier to read. It also brings a lot of complexity in trying to be a p=
erfect proxy. The language might need a better general solution for proxyin=
g, but I don=E2=80=99t think the library needs more wrapper classes that pr=
etend to be invisible.

> There are times when exception are forbidden because of where the code wi=
ll run.=20

Do you mean to say that exception safety is required, or that throw (and an=
y throwing part of the standard library) is forbidden? I think that N4189 m=
akes most sense given the existence of exceptions. And, it doesn=E2=80=99t =
add exception safety over the equivalent manually-defined classes.

> There are times when customer requirements or special cases limit the siz=
e of compiled code, etc., etc.=20

User-defined classes will usually have less overhead than those from templa=
tes like unique_resource. Also, type identity is ensured and easy to reason=
 about, compared to types based only on the resource type (which is likely =
to be HANDLE, int, or the like) and the type of the API function which rele=
ases it (which is likely to be void(HANDLE) or the like). For such cases wi=
th function pointers, the user avoids hidden indirect dispatches by definin=
g a class.

> In each case there are parts of the standard library that apply themselve=
s better than others.  More useful classes like these is always a good thin=
g, even if some people will never use them or understand the benefit they p=
rovide.

Still, utility should be maximized and complexity (particularly runtime ove=
rhead) per class should be minimized.

--=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=_F9A291C0-E114-4F6B-87C0-A18BDD1D0C66
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=
=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=
=E2=80=9311=E2=80=9329, at 1:59 PM, Andrew Sandoval &lt;<a href=3D"mailto:s=
andoval@netwaysglobal.com">sandoval@netwaysglobal.com</a>&gt; wrote:</div><=
br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div class=
=3D"gmail_extra" style=3D"font-family: Helvetica; font-size: 12px; font-sty=
le: normal; font-variant: normal; font-weight: normal; letter-spacing: norm=
al; line-height: normal; orphans: auto; text-align: start; text-indent: 0px=
; text-transform: none; white-space: normal; widows: auto; word-spacing: 0p=
x; -webkit-text-stroke-width: 0px;">I'm not negating the value of uncaught_=
exception, just suggesting that it can't replace the classes proposed in N4=
189.<br></div></blockquote><div><br></div><div><font face=3D"Courier">uncau=
ght_exceptions</font> makes destructors more powerful and N4189 provides ne=
w ways to define destructors. So, they=E2=80=99re complementary.</div><br><=
blockquote type=3D"cite"><div class=3D"gmail_extra" style=3D"font-family: H=
elvetica; font-size: 12px; font-style: normal; font-variant: normal; font-w=
eight: normal; letter-spacing: normal; line-height: normal; orphans: auto; =
text-align: start; text-indent: 0px; text-transform: none; white-space: nor=
mal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I co=
uld give examples, but rather than do that, I would just ask you to think o=
utside of the context you are accustomed to, and realize that there are man=
y environments and situations where these classes will benefit the code bas=
e substantially, even if you can't see it being useful to you.&nbsp; </div>=
</blockquote><div><br></div><div>To me, the comparison is between an explic=
itly-defined destructor in an explicitly-defined class, and the convenience=
 templates in N4189. They are for convenience; there=E2=80=99s no added cap=
ability.</div><div><br></div><div>The concern is that the convenience of <f=
ont face=3D"Courier">unique_resource</font> is negligible because the reade=
r needs to mentally model how it captures state and generates destruction s=
emantics, when the destructor would have been easy to write and much easier=
 to read. It also brings a lot of complexity in trying to be a perfect prox=
y. The language might need a better general solution for proxying, but I do=
n=E2=80=99t think the library needs more wrapper classes that pretend to be=
 invisible.</div><br><blockquote type=3D"cite"><div class=3D"gmail_extra" s=
tyle=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-v=
ariant: normal; font-weight: normal; letter-spacing: normal; line-height: n=
ormal; orphans: auto; text-align: start; text-indent: 0px; text-transform: =
none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-st=
roke-width: 0px;">There are times when exception are forbidden because of w=
here the code will run.&nbsp; </div></blockquote><div><br></div><div>Do you=
 mean to say that exception safety is required, or that&nbsp;<font face=3D"=
Courier">throw</font> (and any throwing part of the standard library) is fo=
rbidden? I think that N4189 makes most sense given the existence of excepti=
ons. And, it doesn=E2=80=99t add exception safety over the equivalent manua=
lly-defined classes.</div><br><blockquote type=3D"cite"><div class=3D"gmail=
_extra" style=3D"font-family: Helvetica; font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;">There are times when customer requirements or sp=
ecial cases limit the size of compiled code, etc., etc.&nbsp; </div></block=
quote><div><br></div><div>User-defined classes will usually have less overh=
ead than those from templates like <font face=3D"Courier">unique_resource</=
font>. Also, type identity is ensured and easy to reason about, compared to=
 types based only on the resource type (which is likely to be <font face=3D=
"Courier">HANDLE</font>, <font face=3D"Courier">int</font>, or the like) an=
d the type of the API function which releases it (which is likely to be <fo=
nt face=3D"Courier">void(HANDLE)</font> or the like). For such cases with f=
unction pointers, the user avoids hidden indirect dispatches by defining a =
class.</div><br><blockquote type=3D"cite"><div class=3D"gmail_extra" style=
=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font-varia=
nt: normal; font-weight: normal; letter-spacing: normal; line-height: norma=
l; orphans: auto; text-align: start; text-indent: 0px; text-transform: none=
; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke=
-width: 0px;">In each case there are parts of the standard library that app=
ly themselves better than others.&nbsp; More useful classes like these is a=
lways a good thing, even if some people will never use them or understand t=
he benefit they provide.</div></blockquote></div><br><div>Still, utility sh=
ould be maximized and complexity (particularly runtime overhead) per class =
should be minimized.</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=_F9A291C0-E114-4F6B-87C0-A18BDD1D0C66--

.

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

On Sat, Nov 29, 2014 at 12:46 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9311=E2=80=9329, at 1:59 PM, Andrew Sandoval <sandoval@netw=
aysglobal.com>
> wrote:
>
> I'm not negating the value of uncaught_exception, just suggesting that it
> can't replace the classes proposed in N4189.
>
>
> uncaught_exceptions makes destructors more powerful and N4189 provides
> new ways to define destructors. So, they=E2=80=99re complementary.
>

No argument there.

>
> I could give examples, but rather than do that, I would just ask you to
> think outside of the context you are accustomed to, and realize that ther=
e
> are many environments and situations where these classes will benefit the
> code base substantially, even if you can't see it being useful to you.
>
>
> To me, the comparison is between an explicitly-defined destructor in an
> explicitly-defined class, and the convenience templates in N4189. They ar=
e
> for convenience; there=E2=80=99s no added capability.
>

One added capability is the ability to see the clean-up of the resource
directly tied to it's allocation in the same "statement."  Destructors are
often far separated from constructors, etc.   As classes grow, resources
can be forgotten -- accidentally left out of the destructor's clean-up.  By
always focusing on the lifetime of the object when it is allocated, this
problem vanishes.

>
> The concern is that the convenience of unique_resource is negligible
> because the reader needs to mentally model how it captures state and
> generates destruction semantics, when the destructor would have been easy
> to write and much easier to read. It also brings a lot of complexity in
> trying to be a perfect proxy. The language might need a better general
> solution for proxying, but I don=E2=80=99t think the library needs more w=
rapper
> classes that pretend to be invisible.
>

Sure, if you are going to encapsulate every resource into its own class
that would make sense.  That is not always desirable.  And let's face it,
it's not that hard to "model".  With unique_resource it is very easy to see
that you are tying the clean-up to the allocation.  The same as you would
with unique_ptr or shared_ptr.

>
> There are times when exception are forbidden because of where the code
> will run.
>
>
> Do you mean to say that exception safety is required, or that throw (and
> any throwing part of the standard library) is forbidden? I think that N41=
89
> makes most sense given the existence of exceptions. And, it doesn=E2=80=
=99t add
> exception safety over the equivalent manually-defined classes.
>

In the cases I'm referring to, throwing anywhere would be a problem.
Kernel drivers, microcontroller code, etc.  Exception handling and throwing
generally require interruptible code, or even allowing for IRQs.  Non
interruptible code is still an ideal place to use RAII for the sake of
managing object lifetime and simplifying code.  These are places
traditionally ruled by C code, but despite not being able to use the full
standard library (without modification), there is no reason to not use RAII
classes as wrappers around resources.  It is lighter weight than full
encapsulation and fits better in the traditional framework of that type of
code.

>
> There are times when customer requirements or special cases limit the siz=
e
> of compiled code, etc., etc.
>
>
> User-defined classes will usually have less overhead than those from
> templates like unique_resource. Also, type identity is ensured and easy
> to reason about, compared to types based only on the resource type (which
> is likely to be HANDLE, int, or the like) and the type of the API
> function which releases it (which is likely to be void(HANDLE) or the
> like). For such cases with function pointers, the user avoids hidden
> indirect dispatches by defining a class.
>

This I disagree with for two reasons.  The first is that unique_resource --
in the cases I've examined compiles down to nothing more than the
equivalent of the old C-style code where a goto error_exit would have been
used to ensure resource clean-up.  In fact, it can result in less runtime
overhead.  And while you might get better type safety from encapsulating
everything in a user-defined class, there are times when this is not
desirably or likely for a host of reasons.  Again, why do we need
unique_ptr?  You could encapsulate every pointer in a user defined class.
Your argument could be made for unique_ptr and shared_ptr.  Having them in
the library though is worthwhile, as it will be with unique_resource and
scope_exit.  Among other things, it provides a way for legacy code (C-style
code) to be fixed without an entire re-write where everything is
encapsulated in a user-defined class.  It provides instant exception safety
(in terms of resource release on unwind) and resolves resource leaks that
are very common in legacy C-style code.

So my point about the many "environment and situations" still holds.  Sure,
there are times when it would be better to write user-defined classes to
encapsulate resources.  But there are definitely times and places where the
generic classes will be a better solution.  Just because it goes against
the way you personally like to work doesn't mean it isn't worthwhile.  I
personally prefer to use RAII classes over full encapsulation, but I
wouldn't want a solution that mandated that for others.

>
> In each case there are parts of the standard library that apply themselve=
s
> better than others.  More useful classes like these is always a good thin=
g,
> even if some people will never use them or understand the benefit they
> provide.
>
>
> Still, utility should be maximized and complexity (particularly runtime
> overhead) per class should be minimized.
>

To my knowledge we can't control implementation details of standard library
classes.  Yes, I hope the implementations have a particularly low runtime
overhead.  In my experience, with current compilers, unique_resource and
scope_exit have a reasonable low overhead -- in some cases zero overhead.
When you work in the types of environments that I mentioned, you have to
know this.  Stack and code space are extremely limited on some
microcontrollers.  And, even on x64/x86 Windows, I've had situation where I
had to verify that my RAII classes added no overhead compared to straight C
code.  Overhead is very easy to check -- just compile to assembly and look
at what is generated.

I believe I understand your arguments -- I just don't think they are
reasons for ruling out these classes.  If that was the direction the
standard library was going to take, that decision should've been made prior
to the addition of unique_ptr, shared_ptr, and even auto_ptr.  scope_exit
and unique_resource compliment unique_ptr and add value to the standard
library.  Flexibility is what has made the standard library great, and is
why C++ is so often superior to alternatives.

-Andrew

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sat, Nov 29, 2014 at 12:46 AM, David Krauss <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word"><br><div><span class=3D""><div>On 2014=E2=80=9311=E2=80=9329, at 1:5=
9 PM, Andrew Sandoval &lt;<a href=3D"mailto:sandoval@netwaysglobal.com" tar=
get=3D"_blank">sandoval@netwaysglobal.com</a>&gt; wrote:</div><br><blockquo=
te type=3D"cite"><div class=3D"gmail_extra" style=3D"font-family:Helvetica;=
font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;let=
ter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text=
-transform:none;white-space:normal;word-spacing:0px">I&#39;m not negating t=
he value of uncaught_exception, just suggesting that it can&#39;t replace t=
he classes proposed in N4189.<br></div></blockquote><div><br></div></span><=
div><font face=3D"Courier">uncaught_exceptions</font> makes destructors mor=
e powerful and N4189 provides new ways to define destructors. So, they=E2=
=80=99re complementary.</div></div></div></blockquote><div><br>No argument =
there. <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div><span class=3D""><br><blockquote type=3D"cite"><div class=3D"=
gmail_extra" style=3D"font-family:Helvetica;font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px">I could give examples, but rather than do that, I wou=
ld just ask you to think outside of the context you are accustomed to, and =
realize that there are many environments and situations where these classes=
 will benefit the code base substantially, even if you can&#39;t see it bei=
ng useful to you.=C2=A0 </div></blockquote><div><br></div></span><div>To me=
, the comparison is between an explicitly-defined destructor in an explicit=
ly-defined class, and the convenience templates in N4189. They are for conv=
enience; there=E2=80=99s no added capability.</div></div></div></blockquote=
><div><br></div><div>One added capability is the ability to see the clean-u=
p of the resource directly tied to it&#39;s allocation in the same &quot;st=
atement.&quot;=C2=A0 Destructors are often far separated from constructors,=
 etc.=C2=A0=C2=A0 As classes grow, resources can be forgotten -- accidental=
ly left out of the destructor&#39;s clean-up.=C2=A0 By always focusing on t=
he lifetime of the object when it is allocated, this problem vanishes.<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><di=
v><div><br></div><div>The concern is that the convenience of <font face=3D"=
Courier">unique_resource</font> is negligible because the reader needs to m=
entally model how it captures state and generates destruction semantics, wh=
en the destructor would have been easy to write and much easier to read. It=
 also brings a lot of complexity in trying to be a perfect proxy. The langu=
age might need a better general solution for proxying, but I don=E2=80=99t =
think the library needs more wrapper classes that pretend to be invisible.<=
/div></div></div></blockquote><div><br></div><div>Sure, if you are going to=
 encapsulate every resource into its own class that would make sense.=C2=A0=
 That is not always desirable.=C2=A0 And let&#39;s face it, it&#39;s not th=
at hard to &quot;model&quot;.=C2=A0 With unique_resource it is very easy to=
 see that you are tying the clean-up to the allocation.=C2=A0 The same as y=
ou would with unique_ptr or shared_ptr.<br></div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><br><blockqu=
ote type=3D"cite"><div class=3D"gmail_extra" style=3D"font-family:Helvetica=
;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;le=
tter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;tex=
t-transform:none;white-space:normal;word-spacing:0px">There are times when =
exception are forbidden because of where the code will run.=C2=A0 </div></b=
lockquote><div><br></div></span><div>Do you mean to say that exception safe=
ty is required, or that=C2=A0<font face=3D"Courier">throw</font> (and any t=
hrowing part of the standard library) is forbidden? I think that N4189 make=
s most sense given the existence of exceptions. And, it doesn=E2=80=99t add=
 exception safety over the equivalent manually-defined classes.</div></div>=
</div></blockquote><div>=C2=A0</div><div>In the cases I&#39;m referring to,=
 throwing anywhere would be a problem.=C2=A0 Kernel drivers, microcontrolle=
r code, etc.=C2=A0 Exception handling and throwing generally require interr=
uptible code, or even allowing for IRQs.=C2=A0 Non interruptible code is st=
ill an ideal place to use RAII for the sake of managing object lifetime and=
 simplifying code.=C2=A0 These are places traditionally ruled by C code, bu=
t despite not being able to use the full standard library (without modifica=
tion), there is no reason to not use RAII classes as wrappers around resour=
ces.=C2=A0 It is lighter weight than full encapsulation and fits better in =
the traditional framework of that type of code.<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div style=3D"word-wrap:break-word"><div><span class=3D""><br=
><blockquote type=3D"cite"><div class=3D"gmail_extra" style=3D"font-family:=
Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:=
normal;letter-spacing:normal;line-height:normal;text-align:start;text-inden=
t:0px;text-transform:none;white-space:normal;word-spacing:0px">There are ti=
mes when customer requirements or special cases limit the size of compiled =
code, etc., etc.=C2=A0 </div></blockquote><div><br></div></span><div>User-d=
efined classes will usually have less overhead than those from templates li=
ke <font face=3D"Courier">unique_resource</font>. Also, type identity is en=
sured and easy to reason about, compared to types based only on the resourc=
e type (which is likely to be <font face=3D"Courier">HANDLE</font>, <font f=
ace=3D"Courier">int</font>, or the like) and the type of the API function w=
hich releases it (which is likely to be <font face=3D"Courier">void(HANDLE)=
</font> or the like). For such cases with function pointers, the user avoid=
s hidden indirect dispatches by defining a class.</div></div></div></blockq=
uote><div><br></div><div>This I disagree with for two reasons.=C2=A0 The fi=
rst is that unique_resource -- in the cases I&#39;ve examined compiles down=
 to nothing more than the equivalent of the old C-style code where a goto e=
rror_exit would have been used to ensure resource clean-up.=C2=A0 In fact, =
it can result in less runtime overhead.=C2=A0 And while you might get bette=
r type safety from encapsulating everything in a user-defined class, there =
are times when this is not desirably or likely for a host of reasons.=C2=A0=
 Again, why do we need unique_ptr?=C2=A0 You could encapsulate every pointe=
r in a user defined class.=C2=A0 Your argument could be made for unique_ptr=
 and shared_ptr.=C2=A0 Having them in the library though is worthwhile, as =
it will be with unique_resource and scope_exit.=C2=A0 Among other things, i=
t provides a way for legacy code (C-style code) to be fixed without an enti=
re re-write where everything is encapsulated in a user-defined class.=C2=A0=
 It provides instant exception safety (in terms of resource release on unwi=
nd) and resolves resource leaks that are very common in legacy C-style code=
..<br><br></div><div>So my point about the many &quot;environment and situat=
ions&quot; still holds.=C2=A0 Sure, there are times when it would be better=
 to write user-defined classes to encapsulate resources.=C2=A0 But there ar=
e definitely times and places where the generic classes will be a better so=
lution.=C2=A0 Just because it goes against the way you personally like to w=
ork doesn&#39;t mean it isn&#39;t worthwhile.=C2=A0 I personally prefer to =
use RAII classes over full encapsulation, but I wouldn&#39;t want a solutio=
n that mandated that for others.<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv style=3D"word-wrap:break-word"><div><span class=3D""><br><blockquote typ=
e=3D"cite"><div class=3D"gmail_extra" style=3D"font-family:Helvetica;font-s=
ize:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-sp=
acing:normal;line-height:normal;text-align:start;text-indent:0px;text-trans=
form:none;white-space:normal;word-spacing:0px">In each case there are parts=
 of the standard library that apply themselves better than others.=C2=A0 Mo=
re useful classes like these is always a good thing, even if some people wi=
ll never use them or understand the benefit they provide.</div></blockquote=
></span></div><br><div>Still, utility should be maximized and complexity (p=
articularly runtime overhead) per class should be minimized.</div></div></b=
lockquote><div><br></div><div>To my knowledge we can&#39;t control implemen=
tation details of standard library classes.=C2=A0 Yes, I hope the implement=
ations have a particularly low runtime overhead.=C2=A0 In my experience, wi=
th current compilers, unique_resource and scope_exit have a reasonable low =
overhead -- in some cases zero overhead.=C2=A0 When you work in the types o=
f environments that I mentioned, you have to know this.=C2=A0 Stack and cod=
e space are extremely limited on some microcontrollers.=C2=A0 And, even on =
x64/x86 Windows, I&#39;ve had situation where I had to verify that my RAII =
classes added no overhead compared to straight C code.=C2=A0 Overhead is ve=
ry easy to check -- just compile to assembly and look at what is generated.=
<br><br></div><div>I believe I understand your arguments -- I just don&#39;=
t think they are reasons for ruling out these classes.=C2=A0 If that was th=
e direction the standard library was going to take, that decision should&#3=
9;ve been made prior to the addition of unique_ptr, shared_ptr, and even au=
to_ptr.=C2=A0 scope_exit and unique_resource compliment unique_ptr and add =
value to the standard library.=C2=A0 Flexibility is what has made the stand=
ard library great, and is why C++ is so often superior to alternatives.<br>=
</div><div><br>-Andrew<br></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 />

--089e0160c3e6864740050907b869--

.

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

Hi Andrew,

  If I may add my own $0.02.

I completely agree with your position. Whether using custom classes or a
generic wrapper is a matter of style, environment, preference, context and
a combination thereof. I don't think unique_resource detracts anything from
the (current) ability to create user-defined wrapper classes while making
it so much easier to write correct (and safe) code to many situations.

You so eloquently wrote:

*One added capability is the ability to see the clean-up of the resource
> directly tied to it's allocation in the same "statement."  Destructors are
> often far separated from constructors, etc.   As classes grow, resources
> can be forgotten -- accidentally left out of the destructor's clean-up.  *
>

I agree that keeping the deleters' close to the initialization is a major
attraction of this proposal (and at the heart of RAII in general).

I do however think that you do not take this concept *far enough*, and
bring up a design decision question re: N4189.

Why does the deleter type need to be part of the class type instead of
using type erasure like with shared_ptr<>?

One of my most common uses for a resource wrapper is as a member variable.

In this case one *cannot* use auto and the deleter has to be stated twice:

   - Once in the resource initialization (as desired);
   - and once inside a "decltype(<deleter>)" in the header file.

This is DRY principle violation, and reduces the utility of the class as a
tool the obviates the coupling between initialization and destruction.

Using "type-erasure" would allow:

   - Defining the deleter just *once* at the point of creation: which is
   the point *you* were making;
   - Allows creating a compilation firewall so that there is no need to
   include (potentially platform-specific) deleter/release headers into your
   class's header file. It would be possible to specify the deleter only in
   the .cpp;
   - If the deleter is a lambda, then the lambda has to either be written
   twice or has to be (1) named and (2) visible in the header file;
   - If the deleter is not a lambda but, say a C function pointer, then if
   is often the case that there is more than onc possible release function
   with the same type. A code change or bug fix that changes the deleter
   function-pointer at initialization but not at the header file, may silently
   compile and run. A future API change or code review may reveal the
   discrepancy and require re-analysis of the code to figure out which one is
   the correct deleter.

IIUC, unique_ptr<>'s avoidance of (shared_ptr<>'s) type-erasure is striving
to provide raw pointer size and efficiency.
In this case you can never know the type, size and/or efficiency aspects of
non-raw-pointer resources used with unique_resource<>, so avoiding
type-erasure seems like premature optimization with some considerable usage
implications.

Of source, it is still possible to implement type-erasure above the
proposed uniqu_resource<>, e.g. as described here
<https://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/> (<
https://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/>), but:

   - Is that the optimal way to do it?
   - Do we expect everyone to do it properly and correctly?
   - Is this the recommended way?
   - If so, shouldn't a similar ErasedPtr<> be part of the proposal, or a
   "using-typedef" at least;

So, to summarize, is the case of a class-member unique-resource not
considered common enough?

Adi

--

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

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

<div dir=3D"ltr">Hi Andrew,<div><br></div><div>=C2=A0 If I may add my own $=
0.02.</div><div><br></div><div>I completely agree with your position. Wheth=
er using custom classes or a generic wrapper is a matter of style, environm=
ent, preference, context and a combination thereof. I don&#39;t think uniqu=
e_resource detracts anything from the (current) ability to create user-defi=
ned wrapper classes while making it so much easier to write correct (and sa=
fe) code to many situations.=C2=A0</div><div><br></div><div>You so eloquent=
ly wrote:</div><div><i><br></i></div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><div><i>One added capability is the ability t=
o see the clean-up of the resource directly tied to it&#39;s allocation in =
the same &quot;statement.&quot;=C2=A0 Destructors are often far separated f=
rom constructors, etc.=C2=A0=C2=A0 As classes grow, resources can be forgot=
ten -- accidentally left out of the destructor&#39;s clean-up. =C2=A0</i><b=
r></div></div></div></div></blockquote><div><br></div><div><div>I agree tha=
t keeping the deleters&#39; close to the initialization is a major attracti=
on of this proposal (and at the heart of RAII in general).</div><div><br></=
div><div>I do however think that you do not take this concept <i>far enough=
</i>, and bring up a design decision question re: N4189.</div><div><br></di=
v><div>Why does the deleter type need to be part of the class type instead =
of using type erasure like with shared_ptr&lt;&gt;?<br></div></div><div><br=
></div><div>One of my most common uses for a resource wrapper is as a membe=
r variable.</div><div><br></div><div>In this case one <i>cannot</i> use aut=
o and the deleter has to be stated twice:</div><div><ul><li>Once in the res=
ource initialization (as desired);</li><li>and once inside a &quot;decltype=
(&lt;deleter&gt;)&quot; in the header file.<br></li></ul></div><div>This is=
 DRY principle violation, and reduces the utility of the class as a tool th=
e obviates the coupling between initialization and destruction.</div><div><=
br></div><div>Using &quot;type-erasure&quot; would allow:</div><div><ul><li=
>Defining the deleter just <i>once</i> at the point of creation: which is t=
he point <i>you</i> were making;</li><li>Allows creating a compilation fire=
wall so that there is no need to include (potentially platform-specific) de=
leter/release headers into your class&#39;s header file. It would be possib=
le to specify the deleter only in the .cpp;</li><li>If the deleter is a lam=
bda, then the lambda has to either be written twice or has to be (1) named =
and (2) visible in the header file;</li><li>If the deleter is not a lambda =
but, say a C function pointer, then if is often the case that there is more=
 than onc possible release function with the same type. A code change or bu=
g fix that changes the deleter function-pointer at initialization but not a=
t the header file, may silently compile and run. A future API change or cod=
e review may reveal the discrepancy and require re-analysis of the code to =
figure out which one is the correct deleter.</li></ul><div>IIUC, unique_ptr=
&lt;&gt;&#39;s avoidance of (shared_ptr&lt;&gt;&#39;s) type-erasure is stri=
ving to provide raw pointer size and efficiency.</div><div>In this case you=
 can never know the type, size and/or efficiency aspects of non-raw-pointer=
 resources used with unique_resource&lt;&gt;, so avoiding type-erasure seem=
s like premature optimization with some considerable usage implications.</d=
iv></div><div><br></div><div>Of source, it is still possible to implement t=
ype-erasure above the proposed uniqu_resource&lt;&gt;, e.g. as <a href=3D"h=
ttps://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/">described =
here</a> (&lt;<a class=3D"" href=3D"https://akrzemi1.wordpress.com/2013/12/=
11/type-erasure-part-iii/">https://akrzemi1.wordpress.com/2013/12/11/type-e=
rasure-part-iii/</a>&gt;), but:</div><div><ul><li>Is that the optimal way t=
o do it?=C2=A0</li><li>Do we expect everyone to do it properly and correctl=
y?=C2=A0<br></li><li>Is this the recommended way?<br></li><li>If so, should=
n&#39;t a similar ErasedPtr&lt;&gt; be part of the proposal, or a &quot;usi=
ng-typedef&quot; at least;</li></ul><div>So, to summarize, is the case of a=
 class-member unique-resource not considered common enough?</div></div><div=
><br></div><div>Adi</div><div><br></div><div><br></div><div><br></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 />

--001a11c3380e61bfab05090f303d--

.

------=_Part_8905_1860161346.1417345766644
Content-Type: multipart/alternative;
 boundary="----=_Part_8906_664809196.1417345766644"

------=_Part_8906_664809196.1417345766644
Content-Type: text/plain; charset=UTF-8

Clarification:

>
>    - If the deleter is a lambda, then the lambda has to either be written
>    twice or has to be (1) named and (2) visible in the header file;
>    - If the deleter is not a lambda but, say a C function pointer, then
>    if is often the case that there is more than one possible release function
>    with the same type. A code change or bug fix that changes the deleter
>    function-pointer at initialization but not at the header file, may silently
>    compile and run. A future API change or code review may reveal the
>    discrepancy and require re-analysis of the code to figure out which one is
>    the correct deleter.
>
> Obviously, these 2 points are disadvantages of the current *non*-type-erased
API. They would both be resolved by using type-erasure.

--

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

<div dir=3D"ltr"><div>Clarification:&nbsp;</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><ul=
><li>If the deleter is a lambda, then the lambda has to either be written t=
wice or has to be (1) named and (2) visible in the header file;</li><li>If =
the deleter is not a lambda but, say a C function pointer, then if is often=
 the case that there is more than one possible release function with the sa=
me type. A code change or bug fix that changes the deleter function-pointer=
 at initialization but not at the header file, may silently compile and run=
.. A future API change or code review may reveal the discrepancy and require=
 re-analysis of the code to figure out which one is the correct deleter.</l=
i></ul></div></div></div></div></blockquote><div>Obviously, these 2 points =
are disadvantages of the current <i>non</i>-type-erased API. They would bot=
h be resolved by using type-erasure.&nbsp;<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_8906_664809196.1417345766644--
------=_Part_8905_1860161346.1417345766644--

.

--047d7bdc9004f6cd290509b67c29
Content-Type: text/plain; charset=UTF-8

On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit <adishavit@gmail.com> wrote:

> Clarification:
>
>>
>>    - If the deleter is a lambda, then the lambda has to either be
>>    written twice or has to be (1) named and (2) visible in the header file;
>>    - If the deleter is not a lambda but, say a C function pointer, then
>>    if is often the case that there is more than one possible release function
>>    with the same type. A code change or bug fix that changes the deleter
>>    function-pointer at initialization but not at the header file, may silently
>>    compile and run. A future API change or code review may reveal the
>>    discrepancy and require re-analysis of the code to figure out which one is
>>    the correct deleter.
>>
>> Obviously, these 2 points are disadvantages of the current *non*-type-erased
> API. They would both be resolved by using type-erasure.
>
> The only problem I see with the type-erased API is that -- if I am reading
it right, it requires use of std::function which IIRC could throw
(allocation failure).  We are trying to avoid anything in the construction
that could throw or having a memory allocation failure, as much as is
possible.

I do like the idea -- and would be in favor of having another RAII class
that was less painful to use a member variable.

-Andrew

--

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit <span dir=3D"ltr">&lt;<a href=
=3D"mailto:adishavit@gmail.com" target=3D"_blank">adishavit@gmail.com</a>&g=
t;</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"><div>Cl=
arification:=C2=A0</div><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"><div><div class=3D"gmail_quote"><div><ul><span class=3D""><li>If the =
deleter is a lambda, then the lambda has to either be written twice or has =
to be (1) named and (2) visible in the header file;</li></span><li>If the d=
eleter is not a lambda but, say a C function pointer, then if is often the =
case that there is more than one possible release function with the same ty=
pe. A code change or bug fix that changes the deleter function-pointer at i=
nitialization but not at the header file, may silently compile and run. A f=
uture API change or code review may reveal the discrepancy and require re-a=
nalysis of the code to figure out which one is the correct deleter.</li></u=
l></div></div></div></div></blockquote><div>Obviously, these 2 points are d=
isadvantages of the current <i>non</i>-type-erased API. They would both be =
resolved by using type-erasure.=C2=A0<br></div></div><div class=3D"HOEnZb">=
<div class=3D"h5">

<p></p></div></div></blockquote></div>The only problem I see with the type-=
erased API is that -- if I am reading it right, it requires use of std::fun=
ction which IIRC could throw (allocation failure).=C2=A0 We are trying to a=
void anything in the construction that could throw or having a memory alloc=
ation failure, as much as is possible.<br><br></div><div class=3D"gmail_ext=
ra">I do like the idea -- and would be in favor of having another RAII clas=
s that was less painful to use a member variable.<br><br></div><div class=
=3D"gmail_extra">-Andrew<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 />

--047d7bdc9004f6cd290509b67c29--

.

On 8 December 2014 at 17:57, Andrew Sandoval <sandoval@netwaysglobal.com> wrote:
>
> On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit <adishavit@gmail.com> wrote:
>>
>> Clarification:
>>>
>>> If the deleter is a lambda, then the lambda has to either be written
>>> twice or has to be (1) named and (2) visible in the header file;
>>> If the deleter is not a lambda but, say a C function pointer, then if is
>>> often the case that there is more than one possible release function with
>>> the same type. A code change or bug fix that changes the deleter
>>> function-pointer at initialization but not at the header file, may silently
>>> compile and run. A future API change or code review may reveal the
>>> discrepancy and require re-analysis of the code to figure out which one is
>>> the correct deleter.
>>
>> Obviously, these 2 points are disadvantages of the current non-type-erased
>> API. They would both be resolved by using type-erasure.
>
> The only problem I see with the type-erased API is that -- if I am reading
> it right, it requires use of std::function which IIRC could throw
> (allocation failure).  We are trying to avoid anything in the construction
> that could throw or having a memory allocation failure, as much as is
> possible.
>
> I do like the idea -- and would be in favor of having another RAII class
> that was less painful to use a member variable.


Is there something preventing using a std::function as a deleter for a
scoped resource?

Also, the "write the lambda twice" case does not exist. Two identical
lambdas are different
types, and you can't decltype a lambda.

Using std::function or any other type erasure mechanism will make it
more likely that
code will compile and run even if that wasn't the intent, not less likely.

--

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

.

--047d7bb040029438460509b6c941
Content-Type: text/plain; charset=UTF-8

>
> The only problem I see with the type-erased API is that -- if I am reading
> it right, it requires use of std::function which IIRC could throw
> (allocation failure).  We are trying to avoid anything in the construction
> that could throw or having a memory allocation failure, as much as is
> possible.
>

The type-erasure example I linked to indeed uses std::function, however:

   - The few implementations of shared_ptr<> that I checked (boost and
   MSVC) do not use std::fucntion for type erasure.
   - I am sure that shared_ptr<>-like guarantees should be sufficient for
   unique_resource.
   - We don't know anything about the resource allocation exception and
   memory guarantees so isn't concern over std::function a bit of a premature
   optimization?
   - We are trying to allocate and manage a resource, in the worse case,
   throwing at construction time, *is* the preferred time for RAII;



> I do like the idea -- and would be in favor of having another RAII class
> that was less painful to use a member variable.
>

Do you think that having a different name (and interface?) for this new
RAII class will make it easier for the user?

Adi

--

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

--047d7bb040029438460509b6c941
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">The only problem I=
 see with the type-erased API is that -- if I am reading it right, it requi=
res use of std::function which IIRC could throw (allocation failure).=C2=A0=
 We are trying to avoid anything in the construction that could throw or ha=
ving a memory allocation failure, as much as is possible.<br></div></div></=
blockquote><div><br></div><div>The type-erasure example I linked to indeed =
uses std::function, however:</div><div><ul><li>The few implementations=C2=
=A0of shared_ptr&lt;&gt;=C2=A0that=C2=A0I checked (boost and MSVC) do not u=
se std::fucntion for type erasure.</li><li>I am sure that shared_ptr&lt;&gt=
;-like guarantees should be sufficient for unique_resource.</li><li>We don&=
#39;t know anything about the resource allocation exception and memory guar=
antees so isn&#39;t concern over std::function a bit of a premature optimiz=
ation? =C2=A0</li><li>We are trying to allocate and manage a resource, in t=
he worse case, throwing at construction time, <i>is</i>=C2=A0the preferred =
time for RAII;</li></ul></div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra"></div><div class=3D"gmail_extra">I do like=
 the idea -- and would be in favor of having another RAII class that was le=
ss painful to use a member variable.</div></div></blockquote><div><br></div=
><div>Do you think that having a different name (and interface?) for this n=
ew RAII class will make it easier for the user?</div><div><br></div><div>Ad=
i</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 />

--047d7bb040029438460509b6c941--

.

--047d7bf0c5380c8e070509b6f4e2
Content-Type: text/plain; charset=UTF-8

Hi Ville,

Is there something preventing using a std::function as a deleter for a
> scoped resource?
>

Of course not. This is exactly what is shown here
<https://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/> (with
the subtleties mentioned there).

As I originally wrote:

Of source, it is still possible to implement type-erasure above the
> proposed uniqu_resource<>, e.g. as described here
> <https://akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/>, but:
>
>    - Is that the optimal way to do it?
>
>
>    - Do we expect everyone to do it properly and correctly?
>
>
>    - Is this the recommended way?
>
>
>    - If so, shouldn't a similar ErasedPtr<> be part of the proposal, or a
>    "using-typedef" at least;
>
>


>
> Also, the "write the lambda twice" case does not exist. Two identical
> lambdas are different
> types, and you can't decltype a lambda.
>

Good point. That means it must be visible at header scope, forcing you to
declare it outside its usage scope and possibly move headers to the header
file breaking the compilation firewall.
This would also mean no lamba-capture and basically goes back to
function-object types declared outside the methods a-la C++98.


>
> Using std::function or any other type erasure mechanism will make it
> more likely that
> code will compile and run even if that wasn't the intent, not less likely.


I don't understand what you mean - I usually do intend for my code to
compile and run ;-).
If you want a *member* unique_resouce<> how is duplication and/or exposing
headers and/or lambda-code better than type-erasure?

Adi

--

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

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

<div dir=3D"ltr">Hi Ville,<div><br></div><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);borde=
r-left-style:solid;padding-left:1ex">Is there something preventing using a =
std::function as a deleter for a<br>
scoped resource?<br></blockquote><div><br></div><div>Of course not. This is=
 exactly what is shown <a href=3D"https://akrzemi1.wordpress.com/2013/12/11=
/type-erasure-part-iii/">here</a>=C2=A0(with the subtleties mentioned there=
).</div><div><br></div><div>As I originally wrote:</div><div><br></div><div=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex" clas=
s=3D"gmail_quote">Of source, it is still possible to implement type-erasure=
 above the proposed uniqu_resource&lt;&gt;, e.g. as=C2=A0<a href=3D"https:/=
/akrzemi1.wordpress.com/2013/12/11/type-erasure-part-iii/" target=3D"_blank=
">described here</a>, but:<ul><li style=3D"margin-left:15px">Is that the op=
timal way to do it?=C2=A0</li></ul><ul><li style=3D"margin-left:15px">Do we=
 expect everyone to do it properly and correctly?=C2=A0</li></ul><ul><li st=
yle=3D"margin-left:15px">Is this the recommended way?</li></ul><ul><li styl=
e=3D"margin-left:15px">If so, shouldn&#39;t a similar ErasedPtr&lt;&gt; be =
part of the proposal, or a &quot;using-typedef&quot; at least;</li></ul></b=
lockquote></div><div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Also, the &quot;write the lambda twice&quot; case does not exist. Two ident=
ical<br>
lambdas are different<br>
types, and you can&#39;t decltype a lambda.<br></blockquote><div><br></div>=
<div>Good point. That means it must be visible at header scope, forcing you=
 to declare it outside its usage scope and possibly move headers to the hea=
der file breaking the compilation firewall.</div><div>This would also mean =
no lamba-capture and basically goes back to function-object types declared =
outside the methods a-la C++98.</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border=
-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Using std::function or any other type erasure mechanism will make it<br>
more likely that<br>
code will compile and run even if that wasn&#39;t the intent, not less like=
ly.</blockquote><div><br></div><div>I don&#39;t understand what you mean - =
I usually do intend for my code to compile and run ;-).</div><div>If you wa=
nt a <i>member</i> unique_resouce&lt;&gt; how is duplication and/or exposin=
g headers and/or lambda-code better than type-erasure?</div><div><br></div>=
<div>Adi=C2=A0</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 />

--047d7bf0c5380c8e070509b6f4e2--

.

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

On Mon, Dec 8, 2014 at 10:12 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 8 December 2014 at 17:57, Andrew Sandoval <sandoval@netwaysglobal.com>
> wrote:
> >
> > On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit <adishavit@gmail.com> wrote:
> >>
> >> Clarification:
> >>>
> >>> If the deleter is a lambda, then the lambda has to either be written
> >>> twice or has to be (1) named and (2) visible in the header file;
> >>> If the deleter is not a lambda but, say a C function pointer, then if
> is
> >>> often the case that there is more than one possible release function
> with
> >>> the same type. A code change or bug fix that changes the deleter
> >>> function-pointer at initialization but not at the header file, may
> silently
> >>> compile and run. A future API change or code review may reveal the
> >>> discrepancy and require re-analysis of the code to figure out which
> one is
> >>> the correct deleter.
> >>
> >> Obviously, these 2 points are disadvantages of the current
> non-type-erased
> >> API. They would both be resolved by using type-erasure.
> >
> > The only problem I see with the type-erased API is that -- if I am
> reading
> > it right, it requires use of std::function which IIRC could throw
> > (allocation failure).  We are trying to avoid anything in the
> construction
> > that could throw or having a memory allocation failure, as much as is
> > possible.
> >
> > I do like the idea -- and would be in favor of having another RAII class
> > that was less painful to use a member variable.
>
>
> Is there something preventing using a std::function as a deleter for a
> scoped resource?
>
> Also, the "write the lambda twice" case does not exist. Two identical
> lambdas are different
> types, and you can't decltype a lambda.
>
> Using std::function or any other type erasure mechanism will make it
> more likely that
> code will compile and run even if that wasn't the intent, not less likely.
> FWIW, this does work:
>
> #include <iostream>
> #include <functional>
> #include "N4189/unique_resource"
> #include "N4189/scope_exit"
>
> class A
> {
> private:
>     std::experimental::unique_resource<int, std::function<void(int)> >
> m_urI;
>     A() = delete;
> public:
>     A(int i) : m_urI(std::move(i), [](int ix) ->void
>     {
>         std::cout << "deleting i: " << ix << std::endl;
>     })
>     {
>     }
>
>     void print()
>     {
>         std::cout << "i is " << m_urI.get() << std::endl;
>     }
> };
>
> int main(int argc, const char*[])
> {
>     A a(10);
>     a.print();
>     return 0;
> }
>

-Andrew

--

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

--001a1133322a24919b0509b708c7
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, Dec 8, 2014 at 10:12 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div class=3D""><div class=3D"h5">On 8 December 2014 at 17:57, =
Andrew Sandoval &lt;<a href=3D"mailto:sandoval@netwaysglobal.com">sandoval@=
netwaysglobal.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit &lt;<a href=3D"mailto:adis=
havit@gmail.com">adishavit@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Clarification:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If the deleter is a lambda, then the lambda has to either be w=
ritten<br>
&gt;&gt;&gt; twice or has to be (1) named and (2) visible in the header fil=
e;<br>
&gt;&gt;&gt; If the deleter is not a lambda but, say a C function pointer, =
then if is<br>
&gt;&gt;&gt; often the case that there is more than one possible release fu=
nction with<br>
&gt;&gt;&gt; the same type. A code change or bug fix that changes the delet=
er<br>
&gt;&gt;&gt; function-pointer at initialization but not at the header file,=
 may silently<br>
&gt;&gt;&gt; compile and run. A future API change or code review may reveal=
 the<br>
&gt;&gt;&gt; discrepancy and require re-analysis of the code to figure out =
which one is<br>
&gt;&gt;&gt; the correct deleter.<br>
&gt;&gt;<br>
&gt;&gt; Obviously, these 2 points are disadvantages of the current non-typ=
e-erased<br>
&gt;&gt; API. They would both be resolved by using type-erasure.<br>
&gt;<br>
&gt; The only problem I see with the type-erased API is that -- if I am rea=
ding<br>
&gt; it right, it requires use of std::function which IIRC could throw<br>
&gt; (allocation failure).=C2=A0 We are trying to avoid anything in the con=
struction<br>
&gt; that could throw or having a memory allocation failure, as much as is<=
br>
&gt; possible.<br>
&gt;<br>
&gt; I do like the idea -- and would be in favor of having another RAII cla=
ss<br>
&gt; that was less painful to use a member variable.<br>
<br>
<br>
</div></div>Is there something preventing using a std::function as a delete=
r for a<br>
scoped resource?<br>
<br>
Also, the &quot;write the lambda twice&quot; case does not exist. Two ident=
ical<br>
lambdas are different<br>
types, and you can&#39;t decltype a lambda.<br>
<br>
Using std::function or any other type erasure mechanism will make it<br>
more likely that<br>
code will compile and run even if that wasn&#39;t the intent, not less like=
ly.<br>
<div class=3D""><div class=3D"h5">FWIW, this does work:<br><br><span style=
=3D"font-family:monospace">#include &lt;iostream&gt;<br>#include &lt;functi=
onal&gt;<br>#include &quot;N4189/unique_resource&quot;<br>#include &quot;N4=
189/scope_exit&quot;<br><br>class A<br>{<br>private:<br>=C2=A0=C2=A0=C2=A0 =
std::experimental::unique_resource&lt;int, std::function&lt;void(int)&gt; &=
gt; m_urI;<br>=C2=A0=C2=A0=C2=A0 A() =3D delete;<br>public:<br>=C2=A0=C2=A0=
=C2=A0 A(int i) : m_urI(std::move(i), [](int ix) -&gt;void<br>=C2=A0=C2=A0=
=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;=
deleting i: &quot; &lt;&lt; ix &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 })=
<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=C2=A0 =
void print()<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=
=A0 std::cout &lt;&lt; &quot;i is &quot; &lt;&lt; m_urI.get() &lt;&lt; std:=
:endl;<br>=C2=A0=C2=A0=C2=A0 }<br>};<br><br>int main(int argc, const char*[=
])<br>{<br>=C2=A0=C2=A0=C2=A0 A a(10);<br>=C2=A0=C2=A0=C2=A0 a.print();<br>=
=C2=A0=C2=A0=C2=A0 return 0;<br>}</span></div></div></blockquote><div><br><=
/div><div>-Andrew <br></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 />

--001a1133322a24919b0509b708c7--

.

On 8 December 2014 at 18:30, Adi Shavit <adishavit@gmail.com> wrote:
> Hi Ville,
>
>> Is there something preventing using a std::function as a deleter for a
>> scoped resource?
> Of course not. This is exactly what is shown here (with the subtleties
> mentioned there).
> As I originally wrote:
>> Of source, it is still possible to implement type-erasure above the
>> proposed uniqu_resource<>, e.g. as described here, but:
>> Is that the optimal way to do it?

Is there a more optimal way?

>> Do we expect everyone to do it properly and correctly?

No, but I expect the technique to be easy enough to explain that it's
not problematic
to do properly and correctly.

>> Is this the recommended way?

When you need it, yes.

>> If so, shouldn't a similar ErasedPtr<> be part of the proposal, or a
>> "using-typedef" at least;

I don't think so.

>> Also, the "write the lambda twice" case does not exist. Two identical
>> lambdas are different
>> types, and you can't decltype a lambda.
> Good point. That means it must be visible at header scope, forcing you to
> declare it outside its usage scope and possibly move headers to the header
> file breaking the compilation firewall.

Or it means that you must use a pointer to function as the type of the deleter
and initialize with a capture-less lambda.

> This would also mean no lamba-capture and basically goes back to
> function-object types declared outside the methods a-la C++98.

Or you can use a std::function as your deleter type and initialize that with
your lambda.

None of this differs from unique_ptr in any way.

>> Using std::function or any other type erasure mechanism will make it
>> more likely that
>> code will compile and run even if that wasn't the intent, not less likely.
>
>
> I don't understand what you mean - I usually do intend for my code to
> compile and run ;-).

I mean your statement
"If the deleter is not a lambda but, say a C function pointer, then if
is often the case that there is more than one possible release
function with the same type. A code change or bug fix that changes the
deleter function-pointer at initialization but not at the header file,
may silently compile and run. A future API change or code review may
reveal the discrepancy and require re-analysis of the code to figure
out which one is the correct deleter."

> If you want a member unique_resouce<> how is duplication and/or exposing
> headers and/or lambda-code better than type-erasure?


I don't need to duplicate/expose headers/lambda-code.

--

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

.

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

Cool. This is indeed what I had in mind.
Maybe the proposal should show this as an additional example for member
usage (where auto cannot be used for the type).
How is this different from "having another RAII class that was less painful
to use a member variable"?

On Mon, Dec 8, 2014 at 6:36 PM, Andrew Sandoval <sandoval@netwaysglobal.com>
wrote:

> On Mon, Dec 8, 2014 at 10:12 AM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>> On 8 December 2014 at 17:57, Andrew Sandoval <sandoval@netwaysglobal.com>
>> wrote:
>> >
>> > On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit <adishavit@gmail.com>
>> wrote:
>> >>
>> >> Clarification:
>> >>>
>> >>> If the deleter is a lambda, then the lambda has to either be written
>> >>> twice or has to be (1) named and (2) visible in the header file;
>> >>> If the deleter is not a lambda but, say a C function pointer, then if
>> is
>> >>> often the case that there is more than one possible release function
>> with
>> >>> the same type. A code change or bug fix that changes the deleter
>> >>> function-pointer at initialization but not at the header file, may
>> silently
>> >>> compile and run. A future API change or code review may reveal the
>> >>> discrepancy and require re-analysis of the code to figure out which
>> one is
>> >>> the correct deleter.
>> >>
>> >> Obviously, these 2 points are disadvantages of the current
>> non-type-erased
>> >> API. They would both be resolved by using type-erasure.
>> >
>> > The only problem I see with the type-erased API is that -- if I am
>> reading
>> > it right, it requires use of std::function which IIRC could throw
>> > (allocation failure).  We are trying to avoid anything in the
>> construction
>> > that could throw or having a memory allocation failure, as much as is
>> > possible.
>> >
>> > I do like the idea -- and would be in favor of having another RAII class
>> > that was less painful to use a member variable.
>>
>>
>> Is there something preventing using a std::function as a deleter for a
>> scoped resource?
>>
>> Also, the "write the lambda twice" case does not exist. Two identical
>> lambdas are different
>> types, and you can't decltype a lambda.
>>
>> Using std::function or any other type erasure mechanism will make it
>> more likely that
>> code will compile and run even if that wasn't the intent, not less likely.
>> FWIW, this does work:
>>
>> #include <iostream>
>> #include <functional>
>> #include "N4189/unique_resource"
>> #include "N4189/scope_exit"
>>
>> class A
>> {
>> private:
>>     std::experimental::unique_resource<int, std::function<void(int)> >
>> m_urI;
>>     A() = delete;
>> public:
>>     A(int i) : m_urI(std::move(i), [](int ix) ->void
>>     {
>>         std::cout << "deleting i: " << ix << std::endl;
>>     })
>>     {
>>     }
>>
>>     void print()
>>     {
>>         std::cout << "i is " << m_urI.get() << std::endl;
>>     }
>> };
>>
>> int main(int argc, const char*[])
>> {
>>     A a(10);
>>     a.print();
>>     return 0;
>> }
>>
>
> -Andrew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/.
>

--

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

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

<div dir=3D"ltr">Cool. This is indeed what I had in mind.<div>Maybe the pro=
posal should show this as an additional example for member usage (where aut=
o cannot be used for the type).</div><div>How is this different from &quot;=
<span style=3D"font-size:13px">having another RAII class that was less pain=
ful to use a member variable</span>&quot;?</div></div><div class=3D"gmail_e=
xtra"><br><div class=3D"gmail_quote">On Mon, Dec 8, 2014 at 6:36 PM, Andrew=
 Sandoval <span dir=3D"ltr">&lt;<a href=3D"mailto:sandoval@netwaysglobal.co=
m" target=3D"_blank">sandoval@netwaysglobal.com</a>&gt;</span> wrote:<br><b=
lockquote 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"><d=
iv class=3D"gmail_quote"><div><div class=3D"h5">On Mon, Dec 8, 2014 at 10:1=
2 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=3D"mailto:ville.vouti=
lainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&gt;</sp=
an> wrote:<br></div></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div><div class=3D"h5"><div><div>On 8 December 2014 at 17:57, Andrew Sando=
val &lt;<a href=3D"mailto:sandoval@netwaysglobal.com" target=3D"_blank">san=
doval@netwaysglobal.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Sun, Nov 30, 2014 at 5:09 AM, Adi Shavit &lt;<a href=3D"mailto:adis=
havit@gmail.com" target=3D"_blank">adishavit@gmail.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Clarification:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; If the deleter is a lambda, then the lambda has to either be w=
ritten<br>
&gt;&gt;&gt; twice or has to be (1) named and (2) visible in the header fil=
e;<br>
&gt;&gt;&gt; If the deleter is not a lambda but, say a C function pointer, =
then if is<br>
&gt;&gt;&gt; often the case that there is more than one possible release fu=
nction with<br>
&gt;&gt;&gt; the same type. A code change or bug fix that changes the delet=
er<br>
&gt;&gt;&gt; function-pointer at initialization but not at the header file,=
 may silently<br>
&gt;&gt;&gt; compile and run. A future API change or code review may reveal=
 the<br>
&gt;&gt;&gt; discrepancy and require re-analysis of the code to figure out =
which one is<br>
&gt;&gt;&gt; the correct deleter.<br>
&gt;&gt;<br>
&gt;&gt; Obviously, these 2 points are disadvantages of the current non-typ=
e-erased<br>
&gt;&gt; API. They would both be resolved by using type-erasure.<br>
&gt;<br>
&gt; The only problem I see with the type-erased API is that -- if I am rea=
ding<br>
&gt; it right, it requires use of std::function which IIRC could throw<br>
&gt; (allocation failure).=C2=A0 We are trying to avoid anything in the con=
struction<br>
&gt; that could throw or having a memory allocation failure, as much as is<=
br>
&gt; possible.<br>
&gt;<br>
&gt; I do like the idea -- and would be in favor of having another RAII cla=
ss<br>
&gt; that was less painful to use a member variable.<br>
<br>
<br>
</div></div>Is there something preventing using a std::function as a delete=
r for a<br>
scoped resource?<br>
<br>
Also, the &quot;write the lambda twice&quot; case does not exist. Two ident=
ical<br>
lambdas are different<br>
types, and you can&#39;t decltype a lambda.<br>
<br>
Using std::function or any other type erasure mechanism will make it<br>
more likely that<br>
code will compile and run even if that wasn&#39;t the intent, not less like=
ly.<br>
</div></div><div><div>FWIW, this does work:<br><br><span style=3D"font-fami=
ly:monospace">#include &lt;iostream&gt;<br>#include &lt;functional&gt;<br>#=
include &quot;N4189/unique_resource&quot;<br>#include &quot;N4189/scope_exi=
t&quot;<br><br>class A<br>{<br>private:<br>=C2=A0=C2=A0=C2=A0 std::experime=
ntal::unique_resource&lt;int, std::function&lt;void(int)&gt; &gt; m_urI;<br=
>=C2=A0=C2=A0=C2=A0 A() =3D delete;<br>public:<br>=C2=A0=C2=A0=C2=A0 A(int =
i) : m_urI(std::move(i), [](int ix) -&gt;void<br>=C2=A0=C2=A0=C2=A0 {<br>=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; &quot;deleting i: =
&quot; &lt;&lt; ix &lt;&lt; std::endl;<br>=C2=A0=C2=A0=C2=A0 })<br>=C2=A0=
=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 }<br><br>=C2=A0=C2=A0=C2=A0 void print=
()<br>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::co=
ut &lt;&lt; &quot;i is &quot; &lt;&lt; m_urI.get() &lt;&lt; std::endl;<br>=
=C2=A0=C2=A0=C2=A0 }<br>};<br><br>int main(int argc, const char*[])<br>{<br=
>=C2=A0=C2=A0=C2=A0 A a(10);<br>=C2=A0=C2=A0=C2=A0 a.print();<br>=C2=A0=C2=
=A0=C2=A0 return 0;<br>}</span></div></div></blockquote><span class=3D"HOEn=
Zb"><font color=3D"#888888"><div><br></div><div>-Andrew <br></div></font></=
span></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/_q-SDzLOsyg=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></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 />

--f46d04182730b269c10509bb730c--

.

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

>
> Is there a more optimal way?
>

I don't know.

>
> >> Do we expect everyone to do it properly and correctly?
>
> No, but I expect the technique to be easy enough to explain that it's
> not problematic
> to do properly and correctly.
>

Perhaps it should be explicitly mentioned in the proposal, since it is not
an obvious solution.


>
> >> Is this the recommended way?
>
> When you need it, yes.
>

Cool. I guess this is what I had in mind for the member usage case.


> <snip>
> Or it means that you must use a pointer to function as the type of the
> deleter
> and initialize with a capture-less lambda.
>
> > This would also mean no lamba-capture and basically goes back to
> > function-object types declared outside the methods a-la C++98.
>
> Or you can use a std::function as your deleter type and initialize that
> with
> your lambda.
>
> None of this differs from unique_ptr in any way.
>

Yes. You are right. This was exactly my point about the type erasure.
All I was suggesting is that using std::function (or any other type-erasure
mechanism) will being added value to unique_resource<>.
If std::function<void(int)> is sufficient, then all is well.
I just wanted to verify that this is the "most optimal" way to do it :-).

I actually had to dig around to figure out that this can actually be done,
so I think it is worth explaining this explicitely in the proposal.


>
> > If you want a member unique_resouce<> how is duplication and/or exposing
> > headers and/or lambda-code better than type-erasure?
>
> I don't need to duplicate/expose headers/lambda-code.


Yes, this is true for the cases of function pointers and when using
std::function<void(int)> (as I suggested).

I think we basically agree that for the member-resource case, an
std::function<void(int)> deleter type can be used for type-erasure (if the
proposal retains the requirement for the the deleter type to be specified).

Adi

--

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

--f46d043c7b486a44670509bba011
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"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddi=
ng-left:1ex">Is there a more optimal way?<br></blockquote><div><br></div><d=
iv>I don&#39;t know.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex">
<span class=3D""><br>
&gt;&gt; Do we expect everyone to do it properly and correctly?<br>
<br>
</span>No, but I expect the technique to be easy enough to explain that it&=
#39;s<br>
not problematic<br>
to do properly and correctly.<br></blockquote><div><br></div><div>Perhaps i=
t should be explicitly mentioned in the proposal, since it is not an obviou=
s solution.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
<span class=3D""><br>
&gt;&gt; Is this the recommended way?<br>
<br>
</span>When you need it, yes.<br></blockquote><div><br></div><div>Cool. I g=
uess this is what I had in mind for the member usage case.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;b=
order-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:s=
olid;padding-left:1ex"><span class=3D"">&lt;snip&gt;<br>
</span>Or it means that you must use a pointer to function as the type of t=
he deleter<br>
and initialize with a capture-less lambda.<br>
<span class=3D""><br>
&gt; This would also mean no lamba-capture and basically goes back to<br>
&gt; function-object types declared outside the methods a-la C++98.<br>
<br>
</span>Or you can use a std::function as your deleter type and initialize t=
hat with<br>
your lambda.<br>
<br>
None of this differs from unique_ptr in any way.<br></blockquote><div><br><=
/div><div>Yes. You are right. This was exactly my point about the type eras=
ure.</div><div>All I was suggesting is that using std::function (or any oth=
er type-erasure mechanism) will being added value to unique_resource&lt;&gt=
;.</div><div>If=C2=A0<span style=3D"font-family:monospace;font-size:10px">s=
td::function&lt;void(int)&gt;</span>=C2=A0is sufficient, then all is well.<=
/div><div>I just wanted to verify that this is the &quot;most optimal&quot;=
 way to do it :-).</div><div><br></div><div>I actually had to dig around to=
 figure out that this can actually be done, so I think it is worth explaini=
ng this explicitely in the proposal.=C2=A0</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width=
:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-lef=
t:1ex"><span class=3D""><br>
</span><span class=3D"">&gt; If you want a member unique_resouce&lt;&gt; ho=
w is duplication and/or exposing<br>
&gt; headers and/or lambda-code better than type-erasure?<br><br>
</span>I don&#39;t need to duplicate/expose headers/lambda-code.</blockquot=
e><div><br></div><div>Yes, this is true for the cases of function pointers =
and when using=C2=A0<span style=3D"font-family:monospace;font-size:10px">st=
d::function&lt;void(int)&gt;</span>=C2=A0(as I suggested).</div><div><br></=
div><div>I think we basically agree that for the member-resource case, an=
=C2=A0<span style=3D"font-family:monospace;font-size:10px">std::function&lt=
;void(int)&gt;</span>=C2=A0deleter type can be used for type-erasure (if th=
e proposal retains the requirement for the the deleter type to be specified=
).=C2=A0</div><div></div></div><br></div><div class=3D"gmail_extra">Adi</di=
v></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 />

--f46d043c7b486a44670509bba011--

.

On 9 December 2014 at 00:05, Adi Shavit <adishavit@gmail.com> wrote:
>> None of this differs from unique_ptr in any way.
>
>
> Yes. You are right. This was exactly my point about the type erasure.
> All I was suggesting is that using std::function (or any other type-erasure
> mechanism) will being added value to unique_resource<>.
> If std::function<void(int)> is sufficient, then all is well.
> I just wanted to verify that this is the "most optimal" way to do it :-).
>
> I actually had to dig around to figure out that this can actually be done,
> so I think it is worth explaining this explicitely in the proposal.

Perhaps. I do vaguely recall that it has been suggested in the
committee discussions
to have a type-erasing resource handle. That has thus far been postponed
to focus on the non-erasing one, I think.

--

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

.