Topic: N3830 - Scoped Resource - Generic RAII Wrapper
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Tue, 28 Jan 2014 09:50:24 -0800 (PST)
Raw View
------=_Part_1540_10112163.1390931424125
Content-Type: text/plain; charset=UTF-8
On Sunday, January 26, 2014 1:16:13 AM UTC-6, 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
>
Adi,
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.
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 a IplImage*, and
to test it for validity, etc. And the nullptr check is built-in so that
you don't need in the lambda.
I hope that helps.
-Andrew Sandoval
--
---
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_1540_10112163.1390931424125
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, January 26, 2014 1:16:13 AM UTC-6, Adi Shavit w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; =
padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width=
: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Hi,</div><div><br><=
/div><div> I've been longing for this for a long time. I look forward=
to seeing something like this in the standard.</div><div><br></div><div>Ho=
w would <font face=3D"courier new, monospace">scoped_resource</font> handle=
release functions that take the address-of the resource?</div><div>I've se=
en 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>.=
</div><div>For example see this: <a onmousedown=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fdocs.opencv.org%2Fmodules%2Fcore%2Fdo=
c%2Fold_basic_structures.html%3Fhighlight%3Dcvreleaseimage%23releaseimage\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNHAcJpIaV9ZoruoRbcTFXiuvcXAgw';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fdocs.=
opencv.org%2Fmodules%2Fcore%2Fdoc%2Fold_basic_structures.html%3Fhighlight%3=
Dcvreleaseimage%23releaseimage\46sa\75D\46sntz\0751\46usg\75AFQjCNHAcJpIaV9=
ZoruoRbcTFXiuvcXAgw';return true;" href=3D"http://docs.opencv.org/modules/c=
ore/doc/old_basic_structures.html?highlight=3Dcvreleaseimage#releaseimage" =
target=3D"_blank">http://docs.opencv.org/<wbr>modules/core/doc/old_basic_<w=
br>structures.html?highlight=3D<wbr>cvreleaseimage#releaseimage</a></div><d=
iv><br></div><div>I guess you could do it with a lambda but then you actual=
ly need a way to reference the resource itself to take its address.</div><d=
iv>Also, writing this lambda every time is tedious and error prone as this =
is quite a common API approach.</div><div><br></div><div>Adi</div></div></b=
lockquote><div><br></div><div>Adi,</div><div><br></div><div>With an API lik=
e that, there are numerous ways you could handle it, but to keep it si=
mple I'd just do something like this:</div><div><br></div><div><font face=
=3D"courier new,monospace">IplImage* pImage =3D</font> <tt class=3D"descnam=
e">cvCreateImage(size, depth, channels);</tt></div><div><tt class=3D"descna=
me">auto releaseImage =3D make_scoped_resource(cvReleaseImage, &pImage,=
nullptr);</tt></div><div><tt class=3D"descname"><br></tt></div><div><tt cl=
ass=3D"descname"><font face=3D"arial,sans-serif">Then the code can go on to=
access the</font> pImage <font face=3D"arial,sans-serif">knowing it's clea=
n-up is managed by</font> releaseImage.<font face=3D"arial,sans-serif">&nbs=
p; 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 en=
sure clean-up doesn't bother me.</font></tt></div><div><tt class=3D"descnam=
e"><br></tt></div><div><tt class=3D"descname"><font face=3D"arial,sans-seri=
f">If you really cared though you could do as I think you were asking:</fon=
t></tt></div><div><tt class=3D"descname"><br></tt></div><div><tt class=3D"d=
escname">auto pImage =3D make_scoped_resource([](IplImage* pImg) ->void<=
/tt></div><div><tt class=3D"descname">{</tt></div><div><tt class=3D"descnam=
e"> cvReleaseImage(&pImg);</tt></div><div><tt class=
=3D"descname">}, cvCreateImage(size, depth, channels), nullptr);</tt></div>=
<div><tt class=3D"descname"><br></tt></div><div><tt class=3D"descname"><fon=
t face=3D"arial,sans-serif">This would allow you to still utilize</font> pI=
mage <font face=3D"arial,sans-serif">in APIs that need a</font> IplImage*, =
<font face=3D"arial,sans-serif">and to test it for validity, etc.</font>&nb=
sp; <font face=3D"arial,sans-serif">And the</font> nullptr <font face=3D"ar=
ial,sans-serif">check is built-in so that you don't need in the lambda.</fo=
nt></tt></div><div><tt class=3D"descname"><font face=3D"arial,sans-serif"><=
br></font></tt></div><div><tt class=3D"descname"><font face=3D"arial,sans-s=
erif">I hope that helps.</font></tt></div><div><tt class=3D"descname"><br><=
/tt></div><div><tt class=3D"descname"><font face=3D"arial,sans-serif">-Andr=
ew Sandoval</font></tt></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" 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 />
------=_Part_1540_10112163.1390931424125--
.
Author: rasin.boris@gmail.com
Date: Thu, 30 Jan 2014 08:56:34 -0800 (PST)
Raw View
------=_Part_969_23385085.1391100995007
Content-Type: text/plain; charset=UTF-8
Hi guys,
I have a slightly different approach to this whole issue.
I imagine unique_resource as a generalization of unique_ptr, which can hold
value of any type, not just pointer.
Then unique_ptr can be redefined in terms of unique_resource, like this:
template <typename T, typename D = std::default_delete<T>>
using unique_ptr = unique_resource<T*, D>;
Specifically, unique_resource would have only these minor differences from
unique_ptr:
1) It will store value of type T, instead of T*.
2) It will not provide default value for Deleter template parameter.
The situation with release function taking address of value would then be
handled like this:
struct release_image { void operator () (IplImage* img) {
cvReleaseImage(&img); }};
typedef std::unique_resource<IplImage*, release_image> image_resource;
auto image = image_resource(cvCreateImage(size, depth, channels));
Also, I think unique_resource would be useful in many more situations in
addition to wrapping "C" API handles.
For example, this is (a schematic) implementation of IP port number
allocator:
class unique_id
{
struct release
{
release(unique_id* id) : id(id) {}
void operator () (int val) { id->_list.push_back(val); }
unique_id* id;
};
public:
unique_resource<int, release> get() { return unique_resource<int,
release> (_list.pop_front(), this); }
private:
std::list<int> _list;
};
--
---
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_969_23385085.1391100995007
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi guys,<br><br>I have a slightly different approach to th=
is whole issue.<br>I imagine unique_resource as a generalization of unique_=
ptr, which can hold value of any type, not just pointer.<br>Then unique_ptr=
can be redefined in terms of unique_resource, like this:<br><br>template &=
lt;typename T, typename D =3D std::default_delete<T>><br>using uni=
que_ptr =3D unique_resource<T*, D>;<br><br>Specifically, unique_resou=
rce would have only these minor differences from unique_ptr:<br><br>1) It w=
ill store value of type T, instead of T*.<br>2) It will not provide default=
value for Deleter template parameter.<br><br>The situation with release fu=
nction taking address of value would then be handled like this:<br><br>stru=
ct release_image { void operator () (IplImage* img) { cvReleaseImage(&i=
mg); }};<br>typedef std::unique_resource<<tt><wbr>IplImage*</tt>, releas=
e_image> image_resource;<br><br>auto image =3D image_resource(cvCreateIm=
age(size, depth, channels));<br><br>Also, I think unique_resource would be =
useful in many more situations in addition to wrapping "C" API handles.<br>=
For example, this is (a schematic) implementation of IP port number allocat=
or:<br><br>class unique_id<br>{<br> struct release<br>&nb=
sp; {<br> release(uni=
que_id* id) : id(id) {}<br> void =
operator () (int val) { id->_list.push_back(val); }<br>  =
; unique_id* id;<br> };<br><br>pu=
blic:<br><br> unique_resource<int, release> get() {=
return unique_resource<int, release> (_list.pop_front(), this); }<br=
><br>private:<br> <br> std::list<int=
> _list;<br><br>};<br><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" 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 />
------=_Part_969_23385085.1391100995007--
.
Author: oblita@gmail.com
Date: Wed, 19 Nov 2014 10:59:51 -0800 (PST)
Raw View
------=_Part_1148_716563424.1416423591290
Content-Type: text/plain; charset=UTF-8
To tell the truth, sometimes I wonder whether providing a solution that
attaches RAII to pointer semantics
(smart pointers) upfront was a mistake, instead of doing it with some
better separation of concerns, and
bring it together. More or less like you said.
On Thursday, January 30, 2014 2:56:34 PM UTC-2, Boris Rasin wrote:
>
> Hi guys,
>
> I have a slightly different approach to this whole issue.
> I imagine unique_resource as a generalization of unique_ptr, which can
> hold value of any type, not just pointer.
> Then unique_ptr can be redefined in terms of unique_resource, like this:
>
> template <typename T, typename D = std::default_delete<T>>
> using unique_ptr = unique_resource<T*, D>;
>
> Specifically, unique_resource would have only these minor differences from
> unique_ptr:
>
> 1) It will store value of type T, instead of T*.
> 2) It will not provide default value for Deleter template parameter.
>
> The situation with release function taking address of value would then be
> handled like this:
>
> struct release_image { void operator () (IplImage* img) {
> cvReleaseImage(&img); }};
> typedef std::unique_resource<IplImage*, release_image> image_resource;
>
> auto image = image_resource(cvCreateImage(size, depth, channels));
>
> Also, I think unique_resource would be useful in many more situations in
> addition to wrapping "C" API handles.
> For example, this is (a schematic) implementation of IP port number
> allocator:
>
> class unique_id
> {
> struct release
> {
> release(unique_id* id) : id(id) {}
> void operator () (int val) { id->_list.push_back(val); }
> unique_id* id;
> };
>
> public:
>
> unique_resource<int, release> get() { return unique_resource<int,
> release> (_list.pop_front(), this); }
>
> private:
>
> std::list<int> _list;
>
> };
>
>
--
---
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_1148_716563424.1416423591290
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">To tell the truth, sometimes I wonder whether providing a =
solution that attaches RAII to pointer semantics<br>(smart pointers) upfron=
t was a mistake, instead of doing it with some better separation of concern=
s, and<br>bring it together. More or less like you said.<br><br>On Thursday=
, January 30, 2014 2:56:34 PM UTC-2, Boris Rasin wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr">Hi guys,<br><br>I have a slightly=
different approach to this whole issue.<br>I imagine unique_resource as a =
generalization of unique_ptr, which can hold value of any type, not just po=
inter.<br>Then unique_ptr can be redefined in terms of unique_resource, lik=
e this:<br><br>template <typename T, typename D =3D std::default_delete&=
lt;T>><br>using unique_ptr =3D unique_resource<T*, D>;<br><br>S=
pecifically, unique_resource would have only these minor differences from u=
nique_ptr:<br><br>1) It will store value of type T, instead of T*.<br>2) It=
will not provide default value for Deleter template parameter.<br><br>The =
situation with release function taking address of value would then be handl=
ed like this:<br><br>struct release_image { void operator () (IplImage* img=
) { cvReleaseImage(&img); }};<br>typedef std::unique_resource<<tt>Ip=
lImage*</tt><wbr>, release_image> image_resource;<br><br>auto image =3D =
image_resource(cvCreateImage(<wbr>size, depth, channels));<br><br>Also, I t=
hink unique_resource would be useful in many more situations in addition to=
wrapping "C" API handles.<br>For example, this is (a schematic) implementa=
tion of IP port number allocator:<br><br>class unique_id<br>{<br> &nbs=
p; struct release<br> {<br> =
release(unique_id* id) : id(id) {}<br> =
void operator () (int val) { id->_list.push_bac=
k(val); }<br> unique_id* id;<br>&=
nbsp; };<br><br>public:<br><br> unique_resour=
ce<int, release> get() { return unique_resource<int, release> (=
_list.pop_front(), this); }<br><br>private:<br> <br> =
; std::list<int> _list;<br><br>};<br><br></div></blockquo=
te></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_1148_716563424.1416423591290--
.
Author: Peter Sommerlad <peter.sommerlad@hsr.ch>
Date: Thu, 20 Nov 2014 16:03:05 +0100
Raw View
--Apple-Mail=_400E10FC-5568-495A-BCE4-0793EDB718BD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
unique_ptr has/will have a bit more of details that I wouldn't want to put =
into unique_resource. However, your approach might work as an implementatio=
n strategy under the as-if rule of the standard. But IMHO this shouldn't be=
put into the standard as a pre-requesite (might incur overhead for some im=
plementations of unique_ptr).
Regards
Peter.
On 30.01.2014, at 17:56, rasin.boris@gmail.com wrote:
> Hi guys,
>=20
> I have a slightly different approach to this whole issue.
> I imagine unique_resource as a generalization of unique_ptr, which can ho=
ld value of any type, not just pointer.
> Then unique_ptr can be redefined in terms of unique_resource, like this:
>=20
> template <typename T, typename D =3D std::default_delete<T>>
> using unique_ptr =3D unique_resource<T*, D>;
>=20
> Specifically, unique_resource would have only these minor differences fro=
m unique_ptr:
>=20
> 1) It will store value of type T, instead of T*.
> 2) It will not provide default value for Deleter template parameter.
>=20
> The situation with release function taking address of value would then be=
handled like this:
>=20
> struct release_image { void operator () (IplImage* img) { cvReleaseImage(=
&img); }};
> typedef std::unique_resource<IplImage*, release_image> image_resource;
>=20
> auto image =3D image_resource(cvCreateImage(size, depth, channels));
>=20
> Also, I think unique_resource would be useful in many more situations in =
addition to wrapping "C" API handles.
> For example, this is (a schematic) implementation of IP port number alloc=
ator:
>=20
> class unique_id
> {
> struct release
> {
> release(unique_id* id) : id(id) {}
> void operator () (int val) { id->_list.push_back(val); }
> unique_id* id;
> };
>=20
> public:
>=20
> unique_resource<int, release> get() { return unique_resource<int, rel=
ease> (_list.pop_front(), this); }
>=20
> private:
> =20
> std::list<int> _list;
>=20
> };
>=20
>=20
> --=20
> =20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
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-propo=
sals/.
--=20
Prof. Peter Sommerlad
Institut f=C3=BCr Software: Bessere Software - Einfach, Schneller!
HSR Hochschule f=C3=BCr Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil
http://ifs.hsr.ch http://cevelop.com http://linticator.com=20
tel:+41 55 222 49 84 =3D=3D mobile:+41 79 432 23 32
fax:+41 55 222 46 29 =3D=3D mailto:peter.sommerlad@hsr.ch
--=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=_400E10FC-5568-495A-BCE4-0793EDB718BD
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=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space;">unique_ptr has/will have=
a bit more of details that I wouldn't want to put into unique_resource. Ho=
wever, your approach might work as an implementation strategy under the as-=
if rule of the standard. But IMHO this shouldn't be put into the standard a=
s a pre-requesite (might incur overhead for some implementations of unique_=
ptr).<div><br></div><div>Regards</div><div>Peter.<br><div><div>On 30.01.201=
4, at 17:56, <a href=3D"mailto:rasin.boris@gmail.com">rasin.boris@gmail.com=
</a> wrote:</div><br class=3D"Apple-interchange-newline"><blockquote type=
=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
<div>
<div dir=3D"ltr">Hi guys,<br>
<br>
I have a slightly different approach to this whole issue.<br>
I imagine unique_resource as a generalization of unique_ptr, which can hold=
value of any type, not just pointer.<br>
Then unique_ptr can be redefined in terms of unique_resource, like this:<br=
>
<br>
template <typename T, typename D =3D std::default_delete<T>><br=
>
using unique_ptr =3D unique_resource<T*, D>;<br>
<br>
Specifically, unique_resource would have only these minor differences from =
unique_ptr:<br>
<br>
1) It will store value of type T, instead of T*.<br>
2) It will not provide default value for Deleter template parameter.<br>
<br>
The situation with release function taking address of value would then be h=
andled like this:<br>
<br>
struct release_image { void operator () (IplImage* img) { cvReleaseImage(&a=
mp;img); }};<br>
typedef std::unique_resource<<tt><wbr>IplImage*</tt>, release_image> =
image_resource;<br>
<br>
auto image =3D image_resource(cvCreateImage(size, depth, channels));<br>
<br>
Also, I think unique_resource would be useful in many more situations in ad=
dition to wrapping "C" API handles.<br>
For example, this is (a schematic) implementation of IP port number allocat=
or:<br>
<br>
class unique_id<br>
{<br>
struct release<br>
{<br>
release(unique_id* id) : id(id) =
{}<br>
void operator () (int val) { id-=
>_list.push_back(val); }<br>
unique_id* id;<br>
};<br>
<br>
public:<br>
<br>
unique_resource<int, release> get() { return uniqu=
e_resource<int, release> (_list.pop_front(), this); }<br>
<br>
private:<br>
<br>
std::list<int> _list;<br>
<br>
};<br>
<br>
</div><div><br class=3D"webkit-block-placeholder"></div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" 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>
</div>
</blockquote></div><br><div apple-content-edited=3D"true">
<span class=3D"Apple-style-span" style=3D"border-collapse: separate; color:=
rgb(0, 0, 0); font-family: Monaco; font-style: normal; font-variant: norma=
l; font-weight: normal; letter-spacing: normal; line-height: normal; orphan=
s: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webki=
t-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; border-spaci=
ng: 0px; color: rgb(0, 0, 0); font-family: Monaco; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; -webkit-text-decorations-in-effect: none; text-in=
dent: 0px; text-transform: none; orphans: 2; white-space: normal; widows: 2=
; word-spacing: 0px;"><div style=3D"word-wrap: break-word; -webkit-nbsp-mod=
e: space; -webkit-line-break: after-white-space;"><div style=3D"margin: 0px=
;">-- </div><div style=3D"margin: 0px;">Prof. Peter Sommerlad</div><di=
v style=3D"margin: 0px; min-height: 14px;"><br></div><div style=3D"margin: =
0px;">Institut f=C3=BCr Software: Bessere Software - Einfach, Schneller!</d=
iv><div style=3D"margin: 0px;">HSR Hochschule f=C3=BCr Technik Rapperswil</=
div><div style=3D"margin: 0px;">Oberseestr 10, Postfach 1475, CH-8640 Rappe=
rswil</div><div style=3D"margin: 0px; min-height: 14px;"><br></div></div></=
span><a href=3D"http://ifs.hsr.ch">http://ifs.hsr.ch</a> <a href=3D"http://=
cevelop.com">http://cevelop.com</a> <a href=3D"http://linticator.com">http:=
//linticator.com</a> <br>tel:+41 55 222 49 84 =3D=3D mobile:+41 79 432=
23 32<div style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webki=
t-line-break: after-white-space; font-size: 12px;"><div style=3D"margin: 0p=
x;">fax:+41 55 222 46 29 =3D=3D <a href=3D"mailto:peter.sommerlad@hsr.ch">m=
ailto:peter.sommerlad@hsr.ch</a></div><div style=3D"margin: 0px;"><br class=
=3D"khtml-block-placeholder"></div><br class=3D"Apple-interchange-newline">=
</div><br class=3D"Apple-interchange-newline"></span><br class=3D"Apple-int=
erchange-newline"><br class=3D"Apple-interchange-newline">
</div>
<br></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" 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=_400E10FC-5568-495A-BCE4-0793EDB718BD--
.
Author: german.gomez@personifyinc.com
Date: Thu, 27 Nov 2014 00:26:46 -0800 (PST)
Raw View
------=_Part_4179_415601844.1417076806752
Content-Type: multipart/alternative;
boundary="----=_Part_4180_1403372064.1417076806752"
------=_Part_4180_1403372064.1417076806752
Content-Type: text/plain; charset=UTF-8
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 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_4180_1403372064.1417076806752
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wonder if we would need this anymore in the language, co=
mpared to a more general<div>scope_guard with failure/exit. std::uncaught_e=
xceptions was recently approved into the standard.<br><br>On Sunday, Januar=
y 26, 2014 2:16:13 PM UTC+7, Adi Shavit wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>Hi,</div><div><br></div><div> I=
've been longing for this for a long time. I look forward to seeing somethi=
ng 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 the address-of the resource?</div><div>I'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>. </div><div>F=
or example see this: <a href=3D"http://docs.opencv.org/modules/core/doc/old=
_basic_structures.html?highlight=3Dcvreleaseimage#releaseimage" target=3D"_=
blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fdocs.opencv.org%2Fmodules%2Fcore%2Fdoc%2Fold_basic_structures.html%3Fhig=
hlight%3Dcvreleaseimage%23releaseimage\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
AcJpIaV9ZoruoRbcTFXiuvcXAgw';return true;" onclick=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fdocs.opencv.org%2Fmodules%2Fcore%2Fdoc%2=
Fold_basic_structures.html%3Fhighlight%3Dcvreleaseimage%23releaseimage\46sa=
\75D\46sntz\0751\46usg\75AFQjCNHAcJpIaV9ZoruoRbcTFXiuvcXAgw';return true;">=
http://docs.opencv.org/<wbr>modules/core/doc/old_basic_<wbr>structures.html=
?highlight=3D<wbr>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 r=
eference the resource itself to take its address.</div><div>Also, writing t=
his lambda every time is tedious and error prone as this is quite a common =
API approach.</div><div><br></div><div>Adi</div></div></blockquote></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" 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_4180_1403372064.1417076806752--
------=_Part_4179_415601844.1417076806752--
.