Topic: Feedback on N3949 - Scoped Resource - Generic
Author: David Krauss <potswa@gmail.com>
Date: Sun, 2 Mar 2014 23:48:05 +0800
Raw View
--Apple-Mail=_17682D05-2F58-4627-9A63-1AB06FEA7E5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 2, 2014, at 8:31 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> 1) I find it odd that scope_guard_t is moveconstructible. QScopedPointer
> isn't, boost::scoped_ptr isn't. If this type is designed to live in one s=
cope
> and not move out of it, it should not be movable, since that allows
> moving it into and out of scopes. If it is designed to be moved into
> and out of scopes, I don't think its name is good.
I think this is an artifact of the requirement that its type must be deduce=
d by a factory function, unlike those other utilities.
The pattern for a factory function of an immovable type is to use copy-list=
-initialization, and declare the local object as a universal reference. See=
my StackOverflow Q&A, Correctly implement finally block using C++ lambda.
> 3) I find the naming of the types and factory functions inconsistent
> with the rest of the standard.
The proposal notes that this is because the guard isn't supposed to be trea=
ted as an object.
IMHO, "scope_guard" names a "thing," which is awkward for a function, and i=
t's a C++-specific buzzword which is not descriptive about what it does for=
the program. For what it's worth, my personal utility is called finally (a=
s you can see in the above SO link).
> 4) unique_resource::operator-> is specified as
> R operator->() const noexcept ;
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
R can't simultaneously be a pointer and class. Perhaps it's supposed to be
is_pointer<R>::value || is_class<R>::value || is_union<R>::value
> I think this is a bit inconsistent with how library usually specifies
> such SFINAE-conditional overloads. It's usually a Remark, so
> I think this should be
What's the point of the restriction anyway? R will seldom if ever be anythi=
ng besides a pointer or class, and the operator-> definition is well-formed=
for any copyable R. (Non-copyable objects are always classes anyway.)
6) The bool execute_on_destruction member is an unnecessary expense for the=
many use cases that don't need release (which itself is an anti-pattern). =
It's not much, but it will affect a lot of code including inner loops.
When I need release, I just capture a local flag and use it within the guar=
d.
bool keep_input =3D false;
auto && guard =3D finally( [&]() noexcept {
if ( ! keep_input ) input.clear();
} );
If the library will support release specially, perhaps it should be factore=
d into a generic one-shot functor utility.
7) scope_guard encapsulates the contained functor, but it's not really an a=
daptor. How about making the deleter member public and calling it invoke? T=
his would avoid hiding the user's own object. With a generic one-shot funct=
or, instead of guard.release() we would have guard.invoke.cancel() which is=
still pretty self-explanatory.
8) Most compilers warn about unused variables, and a guard will never be me=
ntioned after its declaration unless it's released somewhere. There should =
be a provision for touching the guard, such as a no-op member function. Per=
haps call it exiting. The name should reveal that the given guard is being =
"closed" but shouldn't imply that the call is what is closing it. In my lib=
rary, it's a macro named DO_FINALLY but I don't suppose that macros go over=
well in the std lib :) .
9) Perhaps this has been debated, but the requirement "D shall not throw an=
exception" could be strengthened to "D shall be noexcept." See the above S=
tackOverflow link. Ultimately this only requires the user to add the noexce=
pt keyword, but there may be value in that. Or, if proven to have no benefi=
t, the requirement could be relaxed by a later standard revision.
--=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=_17682D05-2F58-4627-9A63-1AB06FEA7E5D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/=
html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"t=
ext/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=
=3D"text/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" con=
tent=3D"text/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-Type"=
content=3D"text/html charset=3Dwindows-1252"><meta http-equiv=3D"Content-T=
ype" content=3D"text/html charset=3Dwindows-1252"><meta http-equiv=3D"Conte=
nt-Type" content=3D"text/html charset=3Dwindows-1252"><meta http-equiv=3D"C=
ontent-Type" content=3D"text/html charset=3Dwindows-1252"></head><body styl=
e=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: a=
fter-white-space;"><br><div><div>On Mar 2, 2014, at 8:31 PM, Ville Voutilai=
nen <<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gm=
ail.com</a>> wrote:</div><br class=3D"Apple-interchange-newline"><blockq=
uote type=3D"cite">1) I find it odd that scope_guard_t is moveconstructible=
.. QScopedPointer<br>isn't, boost::scoped_ptr isn't. If this type is designe=
d to live in one scope<br>and not move out of it, it should not be movable,=
since that allows<br>moving it into and out of scopes. If it is designed t=
o be moved into<br>and out of scopes, I don't think its name is good.<br></=
blockquote><div><br></div><div>I think this is an artifact of the requireme=
nt that its type must be deduced by a factory function, unlike those other =
utilities.</div><div><br></div><div>The pattern for a factory function of a=
n immovable type is to use copy-list-initialization, and declare the local =
object as a universal reference. See my StackOverflow Q&A, <a href=
=3D"http://stackoverflow.com/q/17356258/153285">Correctly implement finally=
block using C++ lambda</a>.</div><div><br></div><div><br></div><blockquote=
type=3D"cite">3) I find the naming of the types and factory functions inco=
nsistent<br>with the rest of the standard.<br></blockquote><div><br></div><=
div>The proposal notes that this is because the guard isn’t supposed =
to be treated as an object.</div><div><br></div><div>IMHO, “<font fac=
e=3D"Courier">scope_guard</font>” names a “thing,” which =
is awkward for a function, and it's a C++-specific buzzword which is not de=
scriptive about what it does for the program. For what it’s worth, my=
personal utility is called <font face=3D"Courier">finally</font> (as =
you can see in the above SO link).</div><div><br></div><br><blockquote type=
=3D"cite">4) unique_resource::operator-> is specified as<br>R operator-&=
gt;() const noexcept ;<br>Requires:<br>operator-><br>is only available i=
f<br>is_pointer<R>::value && (is_class<R>::value || is_=
union<R>::value)<br></blockquote><div><br></div><div>R can’t si=
multaneously be a pointer and class. Perhaps it's supposed to be</div><div>=
<br></div><div><font face=3D"Courier">is_pointer<R>::value || is_clas=
s<R>::value || is_union<R>::value</font></div><br><blockquote t=
ype=3D"cite">I think this is a bit inconsistent with how library usually sp=
ecifies<br>such SFINAE-conditional overloads. It's usually a Remark, so<br>=
I think this should be<br></blockquote><div><br></div><div>What’s the=
point of the restriction anyway? <font face=3D"Courier">R</font> will seld=
om if ever be anything besides a pointer or class, and the <font face=3D"Co=
urier">operator-></font> definition is well-formed for any copyable=
<span style=3D"font-family: Courier;">R</span>. (Non-copyable objects=
are always classes anyway.)</div></div><div><br></div><br><div>6) The bool=
<font face=3D"Courier">execute_on_destruction</font> member is an unnecess=
ary expense for the many use cases that don’t need <font face=3D"Cour=
ier">release</font> (which itself is an anti-pattern). It’s not =
much, but it will affect a lot of code including inner loops.</div><div><br=
></div><div>When I need <font face=3D"Courier">release</font>, I just captu=
re a local flag and use it within the guard.</div><div><br></div><div><div>=
<font face=3D"Courier">bool keep_input =3D false;</font></div><div><font fa=
ce=3D"Courier">auto && guard =3D finally( [&]() noexcept {</fon=
t></div><div><font face=3D"Courier"> if ( ! </font><span =
style=3D"font-family: Courier;">keep_input</span><font face=3D"Courier">&nb=
sp;) input.clear();</font></div><div><font face=3D"Courier">} );</font></di=
v></div><div><br></div><div>If the library will support <font face=3D"Couri=
er">release</font> specially, perhaps it should be factored into a generic =
one-shot functor utility.</div><div><br></div><div><br></div><div>7) <font =
face=3D"Courier">scope_guard</font> encapsulates the contained functor=
, but it’s not really an adaptor. How about making the <font face=3D"=
Courier">deleter</font> member public and calling it <font face=3D"Cou=
rier">invoke</font>? This would avoid hiding the user’s own object. W=
ith a generic one-shot functor, instead of <font face=3D"Courier">guar=
d.release()</font> we would have <font face=3D"Courier">guard.invoke.c=
ancel()</font> which is still pretty self-explanatory.</div><div><br><=
/div><div><br></div><div>8) Most compilers warn about unused variables, and=
a guard will never be mentioned after its declaration unless it’s re=
leased somewhere. There should be a provision for touching the guard, such =
as a no-op member function. Perhaps call it <font face=3D"Courier">exiting<=
/font>. The name should reveal that the given guard is being “closed&=
rdquo; but shouldn’t imply that the call is what is closing it. In my=
library, it’s a macro named <font face=3D"Courier">DO_FINALLY</font>=
but I don’t suppose that macros go over well in the std lib :) =
..</div><div><br></div><div><br></div><div>9) Perhaps this has been debated,=
but the requirement “<font face=3D"Courier">D</font> shall not throw=
an exception” could be strengthened to “<font face=3D"Courier"=
>D</font> shall be <font face=3D"Courier">noexcept</font>.” See the a=
bove StackOverflow link. Ultimately this only requires the user to add the&=
nbsp;<span style=3D"font-family: Courier;">noexcept</span> keyword, bu=
t there may be value in that. Or, if proven to have no benefit, the require=
ment could be relaxed by a later standard revision.</div><div><br></div><di=
v><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=_17682D05-2F58-4627-9A63-1AB06FEA7E5D--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 19:47:31 +0200
Raw View
On 2 March 2014 17:48, David Krauss <potswa@gmail.com> wrote:
>
> On Mar 2, 2014, at 8:31 PM, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>
> 1) I find it odd that scope_guard_t is moveconstructible. QScopedPointer
> isn't, boost::scoped_ptr isn't. If this type is designed to live in one
> scope
> and not move out of it, it should not be movable, since that allows
> moving it into and out of scopes. If it is designed to be moved into
> and out of scopes, I don't think its name is good.
>
>
> I think this is an artifact of the requirement that its type must be deduced
> by a factory function, unlike those other utilities.
Well, good point, but I now realize that it's not an artifact of having to
deduce the type, but an artifact of having to be able to return the type
from a factory type. Move construction must be valid for that use even
if it's elided. So we'll have to keep the move construction, unfortunately.
>
> The pattern for a factory function of an immovable type is to use
> copy-list-initialization, and declare the local object as a universal
> reference. See my StackOverflow Q&A, Correctly implement finally block using
> C++ lambda.
Urgh.
>
>
> 3) I find the naming of the types and factory functions inconsistent
> with the rest of the standard.
> The proposal notes that this is because the guard isn't supposed to be
> treated as an object.
Well, unique_resource most certainly _will_ be treated as an object.
And not everybody will use auto with it. People will store unique_resources
in containers.
> 4) unique_resource::operator-> is specified as
> R operator->() const noexcept ;
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> R can't simultaneously be a pointer and class. Perhaps it's supposed to be
> is_pointer<R>::value || is_class<R>::value || is_union<R>::value
Nice catch.
>
> I think this is a bit inconsistent with how library usually specifies
> such SFINAE-conditional overloads. It's usually a Remark, so
> I think this should be
> What's the point of the restriction anyway? R will seldom if ever be
> anything besides a pointer or class, and the operator-> definition is
> well-formed for any copyable R. (Non-copyable objects are always classes
> anyway.)
operator-> is not valid for a resource that holds an int, for example.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 19:48:09 +0200
Raw View
On 2 March 2014 19:47, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> Well, good point, but I now realize that it's not an artifact of having to
> deduce the type, but an artifact of having to be able to return the type
> from a factory type. Move construction must be valid for that use even
Sigh, factory _function_...
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 02:08:14 +0800
Raw View
--Apple-Mail=_81527C4F-4DFC-41C0-9493-29580E16A543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 1:47 AM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> Well, good point, but I now realize that it's not an artifact of having t=
o
> deduce the type, but an artifact of having to be able to return the type
> from a factory type.
Well, the factory only exists to perform deduction. But moving on...
> Urgh.
So, move construction does not need to be allowed, if auto && is required. =
This is the better design choice. For comparison, the original scope_guard =
required use of const & to get around C++03 limitations of initialization a=
nd persistence in the absence of auto.
It's also the only way a guard can work without that internal Boolean flag,=
which is necessary to make the usually-elided move constructor do the righ=
t thing.
>> 3) I find the naming of the types and factory functions inconsistent
>> with the rest of the standard.
>> The proposal notes that this is because the guard isn't supposed to be
>> treated as an object.
>=20
> Well, unique_resource most certainly _will_ be treated as an object.
> And not everybody will use auto with it. People will store unique_resourc=
es
> in containers.
Agreed. Actually the given justification is "because they actually do not a=
llocate any resources, like std::make_unique or std::make_shared do." But t=
here are other non-allocating factory functions like make_tuple. My brain q=
uietly substituted "object" for "resource."
>> What's the point of the restriction anyway? R will seldom if ever be
>> anything besides a pointer or class, and the operator-> definition is
>> well-formed for any copyable R. (Non-copyable objects are always classes
>> anyway.)
>=20
> operator-> is not valid for a resource that holds an int, for example.
That wouldn't be much of a resource. Anyway, as I said, the member declarat=
ion, and function body, are still valid. GCC and Clang -pedantic don't warn=
about such a declaration. It's useless, but harmless. (On the other hand, =
we've already had a bug with the SFINAE here ;v) .)
--=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=_81527C4F-4DFC-41C0-9493-29580E16A543
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 1:47 AM, Ville Voutilainen <<a href=3D"mailto:ville.voutilain=
en@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">Well, good point, but =
I now realize that it's not an artifact of having to<br>deduce the type, bu=
t an artifact of having to be able to return the type<br>from a factory typ=
e.</blockquote><div><br></div><div>Well, the factory only exists to perform=
deduction. But moving on…</div><br><blockquote type=3D"cite">Urgh.<=
br></blockquote><div><br></div><div>So, move construction does not need to =
be allowed, if <font face=3D"Courier">auto &&</font> is required. T=
his is the better design choice. For comparison, the original <font face=3D=
"Courier">scope_guard</font> required use of <font face=3D"Courier">co=
nst &</font> to get around C++03 limitations of initialization and=
persistence in the absence of <font face=3D"Courier">auto</font>.</div><di=
v><br></div><div>It’s also the only way a guard can work without that=
internal Boolean flag, which is necessary to make the usually-elided move =
constructor do the right thing.</div><br><blockquote type=3D"cite"><blockqu=
ote type=3D"cite">3) I find the naming of the types and factory functions i=
nconsistent<br>with the rest of the standard.<br>The proposal notes that th=
is is because the guard isn't supposed to be<br>treated as an object.<br></=
blockquote><br>Well, unique_resource most certainly _will_ be treated as an=
object.<br>And not everybody will use auto with it. People will store uniq=
ue_resources<br>in containers.<br></blockquote><div><br></div>Agreed. Actua=
lly the given justification is "because they actually do not allocate =
any resources, like <font face=3D"Courier">std::make_unique</font>&n=
bsp;or <font face=3D"Courier">std::make_shared</font> do.” But t=
here are other non-allocating factory functions like <font face=3D"Courier"=
>make_tuple</font>. My brain quietly substituted “object” for &=
ldquo;resource.”</div><div><br><blockquote type=3D"cite"><blockquote =
type=3D"cite">What's the point of the restriction anyway? R will seldom if =
ever be</blockquote><blockquote type=3D"cite">anything besides a pointer or=
class, and the operator-> definition is<br>well-formed for any copyable=
R. (Non-copyable objects are always classes<br>anyway.)<br></blockquote><b=
r>operator-> is not valid for a resource that holds an int, for example.=
<br></blockquote><div><br></div>That wouldn’t be much of a resource. =
Anyway, as I said, the member declaration, and function body, are still val=
id. GCC and Clang <font face=3D"Courier">-pedantic</font> don’t warn =
about such a declaration. It’s useless, but harmless. (On the other h=
and, we’ve already had a bug with the SFINAE here ;v) .)</div><div><b=
r></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=_81527C4F-4DFC-41C0-9493-29580E16A543--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 20:11:23 +0200
Raw View
On 2 March 2014 20:08, David Krauss <potswa@gmail.com> wrote:
> operator-> is not valid for a resource that holds an int, for example.
> That wouldn't be much of a resource. Anyway, as I said, the member
It happens to be a very common resource, a resource that is the
result of open() on POSIX platforms.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 02:14:26 +0800
Raw View
--Apple-Mail=_E01B6489-DC0E-4909-8133-C9433C7D3118
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 2:11 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 2 March 2014 20:08, David Krauss <potswa@gmail.com> wrote:
>> operator-> is not valid for a resource that holds an int, for example.
>> That wouldn't be much of a resource. Anyway, as I said, the member
>
> It happens to be a very common resource, a resource that is the
> result of open() on POSIX platforms.
Fair nuff. Again, the existence of int operator->() { return r; } is not a problem. Its selection by operator overloading would require diagnosis, that's all.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_E01B6489-DC0E-4909-8133-C9433C7D3118
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 2:11 AM, Ville Voutilainen <<a href=3D"mailto:ville.voutilain=
en@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">On 2 March 2014 20:08,=
David Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>&=
gt; wrote:<br><blockquote type=3D"cite">operator-> is not valid for a re=
source that holds an int, for example.<br>That wouldn't be much of a resour=
ce. Anyway, as I said, the member<br></blockquote><br>It happens to be a ve=
ry common resource, a resource that is the<br>result of open() on POSIX pla=
tforms.<br></blockquote><div><br></div><div>Fair nuff. Again, the existence=
of <font face=3D"Courier">int operator->() { return r; }</font> is not =
a problem. Its selection by operator overloading would require diagnosis, t=
hat’s all.</div></div><br></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 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 />
--Apple-Mail=_E01B6489-DC0E-4909-8133-C9433C7D3118--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 02:17:35 +0800
Raw View
--Apple-Mail=_745E6FE7-7BF1-4747-9DBD-60E7412237C2
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 2:14 AM, David Krauss <potswa@gmail.com> wrote:
> int operator->() { return r; }
Wait-a-minute. The return type needs to be R & if it's going to work with class type. (This is a separate bug in the proposal, irrelevant to the int case.)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_745E6FE7-7BF1-4747-9DBD-60E7412237C2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 2:14 AM, David Krauss <<a href=3D"mailto:potswa@gmail.com">po=
tswa@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=3Dwindows-1252"><div style=3D"word-wrap: break-word; -webkit-=
nbsp-mode: space; -webkit-line-break: after-white-space;"> <font face=
=3D"Courier">int operator->() { return r; }</font> </div></blockquo=
te><br></div><div>Wait-a-minute. The return type needs to be <font face=3D"=
Courier">R &</font> if it’s going to work with class type. (This =
is a separate bug in the proposal, irrelevant to the <font face=3D"Courier"=
>int</font> case.)</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=_745E6FE7-7BF1-4747-9DBD-60E7412237C2--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 20:21:27 +0200
Raw View
On 2 March 2014 20:17, David Krauss <potswa@gmail.com> wrote:
> int operator->() { return r; }
> Wait-a-minute. The return type needs to be R & if it's going to work with
> class type. (This is a separate bug in the proposal, irrelevant to the int
> case.)
Hmm, indeed, the operator* will return R& for that case, but operator->
seems to return R, not R&.
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sun, 2 Mar 2014 20:27:38 +0200
Raw View
On 2 March 2014 20:14, David Krauss <potswa@gmail.com> wrote:
> Fair nuff. Again, the existence of int operator->() { return r; } is not a
> problem. Its selection by operator overloading would require diagnosis,
> that's all.
I think it's a problem that it's there. It can be called directly, and
that "works",
but using it as an operator doesn't work. Hence it should be SFINAED away.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 08:12:54 +0800
Raw View
--Apple-Mail=_702FF4B7-59BA-4FB2-9513-9549CED5B747
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 2:27 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 2 March 2014 20:14, David Krauss <potswa@gmail.com> wrote:
>> Fair nuff. Again, the existence of int operator->() { return r; } is not a
>> problem. Its selection by operator overloading would require diagnosis,
>> that's all.
>
>
> I think it's a problem that it's there. It can be called directly, and
> that "works",
> but using it as an operator doesn't work. Hence it should be SFINAED away.
Iterators (of class type) over integral sequences all have a similar operator-> and it never seems to bother anyone.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--Apple-Mail=_702FF4B7-59BA-4FB2-9513-9549CED5B747
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Diso-8859-1"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mo=
de: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3, =
2014, at 2:27 AM, Ville Voutilainen <<a href=3D"mailto:ville.voutilainen=
@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><blockquote type=3D"cite">On 2 March 2014 20:14, D=
avid Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>>=
; wrote:<br><blockquote type=3D"cite">Fair nuff. Again, the existence of in=
t operator->() { return r; } is not a<br>problem. Its selection by opera=
tor overloading would require diagnosis,<br>that's all.<br></blockquote><br=
><br>I think it's a problem that it's there. It can be called directly, and=
<br>that "works",<br>but using it as an operator doesn't work. Hence it sho=
uld be SFINAED away.<br></blockquote><div><br></div><div>Iterators (of clas=
s type) over integral sequences all have a similar <font face=3D"Courier">o=
perator-></font> and it never seems to bother anyone.</div><div><br></di=
v></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=_702FF4B7-59BA-4FB2-9513-9549CED5B747--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 3 Mar 2014 07:59:01 +0200
Raw View
On 3 March 2014 02:12, David Krauss <potswa@gmail.com> wrote:
>> I think it's a problem that it's there. It can be called directly, and
>> that "works",
>> but using it as an operator doesn't work. Hence it should be SFINAED away.
> Iterators (of class type) over integral sequences all have a similar
> operator-> and it never seems to bother anyone.
I don't think such iterators should have such an operator->.
[iterator.requirements.general]/1 says
"All iterators i for which the expression (*i).m is well-defined, support the
expression i->m with the same semantics as (*i).m. "
For the iterators in case here, (*i).m is not well-defined, so they shouldn't
support operator->.
--
---
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/.
.
Author: vadim.petrochenkov@gmail.com
Date: Sun, 2 Mar 2014 22:07:39 -0800 (PST)
Raw View
------=_Part_3356_6347186.1393826859380
Content-Type: text/plain; charset=UTF-8
What do you think about this proposal and its future? Template parameter
deduction for constructors<http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html>
It'd solve some present and future library inconveniences, including
scope_guard and unique_resource, if ready in time.
On Sunday, March 2, 2014 4:31:59 PM UTC+4, Ville Voutilainen wrote:
>
> 1) I find it odd that scope_guard_t is moveconstructible. QScopedPointer
> isn't, boost::scoped_ptr isn't. If this type is designed to live in one
> scope
> and not move out of it, it should not be movable, since that allows
> moving it into and out of scopes. If it is designed to be moved into
> and out of scopes, I don't think its name is good.
>
> 2) minor nit: the deleted copy assignment operator for scope_guard_t
> is void operator=(scope_guard_t const &)=delete;, the return type
> is void, which is not the usual canonical form. The move assignment
> operator isn't deleted, but it doesn't have to be since it will be
> suppressed.
> I would recommend explicitly deleting all copy/move operations
> explicitly, so that implementations give better diagnostics.
>
> 3) I find the naming of the types and factory functions inconsistent
> with the rest of the standard. This proposal uses scope_guard_t and
> unique_resource_t as the types, and scope_guard and
> unique_resource(_checked)
> as the factory functions. I'd find it more consistent to have scope_guard
> and unique_resource as the types and make_scope_guard and
> make_unique_resource(_checked) as the factories. Sure, they are
> longer to type, but they would be consistent.
>
> 4) unique_resource::operator-> is specified as
> R operator->() const noexcept ;
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
>
> I think this is a bit inconsistent with how library usually specifies
> such SFINAE-conditional overloads. It's usually a Remark, so
> I think this should be
> <del>
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
> </del>
> <ins>
> Remarks:
> This function shall not participate in overload resolution unless
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
> </ins>
>
> We certainly don't want to have it as Requires, since usually violating
> a Requires-clause results in undefined behavior. Same issue with
> operator*,
>
> see below operator*() const noexcept;
> <del>
> Requires:
> This function is only available if
> is_pointer<R>::value is true.
> </del>
> <ins>
> Remarks:
> This function shall not participate in overload resolution unless
> is_pointer<R>::value is true.
> </ins>
>
> 5) unique_resource::get_deleter is specified as
> const DELETER & get_deleter() const noexcept;
> but the name of the template parameter is D, so
> this should now be
>
> const D& get_deleter() const noexcept;
>
>
>
> I think the proposal is otherwise ok. :)
>
--
---
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_3356_6347186.1393826859380
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What do you think about this proposal and its future? =
;<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2013/n3602.html"=
style=3D"font-size: 16px; line-height: 24px; font-family: 'Times New Roman=
';">Template parameter deduction for constructors</a><br><br>It'd solve som=
e present and future library inconveniences, including scope_guard and=
unique_resource, if ready in time.<br><br>On Sunday, March 2, 2014 4:=
31:59 PM UTC+4, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">1) I find it odd that scope_guard_t is moveconstructible. QScoped=
Pointer
<br>isn't, boost::scoped_ptr isn't. If this type is designed to live in one=
scope
<br>and not move out of it, it should not be movable, since that allows
<br>moving it into and out of scopes. If it is designed to be moved into
<br>and out of scopes, I don't think its name is good.
<br>
<br>2) minor nit: the deleted copy assignment operator for scope_guard_t
<br>is void operator=3D(scope_guard_t const &)=3Ddelete;, the return ty=
pe
<br>is void, which is not the usual canonical form. The move assignme=
nt
<br>operator isn't deleted, but it doesn't have to be since it will be supp=
ressed.
<br>I would recommend explicitly deleting all copy/move operations
<br>explicitly, so that implementations give better diagnostics.
<br>
<br>3) I find the naming of the types and factory functions inconsistent
<br>with the rest of the standard. This proposal uses scope_guard_t and
<br>unique_resource_t as the types, and scope_guard and unique_resource(_ch=
ecked)
<br>as the factory functions. I'd find it more consistent to have scope_gua=
rd
<br>and unique_resource as the types and make_scope_guard and
<br>make_unique_resource(_checked) as the factories. Sure, they are
<br>longer to type, but they would be consistent.
<br>
<br>4) unique_resource::operator-> is specified as
<br>R operator->() const noexcept ;
<br>Requires:
<br>operator->
<br>is only available if
<br>is_pointer<R>::value && (is_class<R>::value || is_u=
nion<R>::value)
<br>is true.
<br>
<br>I think this is a bit inconsistent with how library usually specifies
<br>such SFINAE-conditional overloads. It's usually a Remark, so
<br>I think this should be
<br><del>
<br>Requires:
<br>operator->
<br>is only available if
<br>is_pointer<R>::value && (is_class<R>::value || is_u=
nion<R>::value)
<br>is true.
<br></del>
<br><ins>
<br>Remarks:
<br>This function shall not participate in overload resolution unless
<br>is_pointer<R>::value && (is_class<R>::value || is_u=
nion<R>::value)
<br>is true.
<br></ins>
<br>
<br>We certainly don't want to have it as Requires, since usually violating
<br>a Requires-clause results in undefined behavior. Same issue with
<br>operator*,
<br>
<br>see below operator*() const noexcept;
<br><del>
<br>Requires:
<br>This function is only available if
<br>is_pointer<R>::value is true.
<br></del>
<br><ins>
<br>Remarks:
<br>This function shall not participate in overload resolution unless
<br>is_pointer<R>::value is true.
<br></ins>
<br>
<br>5) unique_resource::get_deleter is specified as
<br>const DELETER & get_deleter() const noexcept;
<br>but the name of the template parameter is D, so
<br>this should now be
<br>
<br>const D& get_deleter() const noexcept;
<br>
<br>
<br>
<br>I think the proposal is otherwise ok. :)
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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_3356_6347186.1393826859380--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 15:08:46 +0800
Raw View
--Apple-Mail=_9D055DBC-1E26-4D3B-A898-5BB13B3BFFFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 1:59 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> I don't think such iterators should have such an operator->.
> [iterator.requirements.general]/1 says
> "All iterators i for which the expression (*i).m is well-defined, support=
the
> expression i->m with the same semantics as (*i).m. "
> For the iterators in case here, (*i).m is not well-defined, so they shoul=
dn't
> support operator->.
The standard simply doesn't discuss the implementation of iterator operator=
->. It does not require the function to exist, but neither does it forbid i=
t, and it's such a minor QOI issue that nobody cares. SFINAE is just a hoop=
to jump through here, and it makes implementation bugs more likely.
You could say the same for operator*; it exists for an int resource but usi=
ng it results in an ill-formed implicit specialization. This also has the e=
ffect of making the class impossible to explicitly instantiate, which may b=
e a real issue.
Requirement lists avoid the over-specification tendency of informative decl=
arations. It would be better never to mention operator-> and operator* by n=
ame at all, perhaps by introduction of a Dereferenceable concept.
--=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=_9D055DBC-1E26-4D3B-A898-5BB13B3BFFFC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 1:59 PM, Ville Voutilainen <<a href=3D"mailto:ville.voutilain=
en@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">I don't think such ite=
rators should have such an operator->.<br>[iterator.requirements.general=
]/1 says<br>"All iterators i for which the expression (*i).m is well-define=
d, support the<br>expression i->m with the same semantics as (*i).m. "<b=
r>For the iterators in case here, (*i).m is not well-defined, so they shoul=
dn't<br>support operator->.<br></blockquote><div><br></div><div>The stan=
dard simply doesn’t discuss the implementation of iterator <font face=
=3D"Courier">operator-></font>. It does not require the function to exis=
t, but neither does it forbid it, and it’s such a minor QOI issue tha=
t nobody cares. SFINAE is just a hoop to jump through here, and it makes im=
plementation bugs more likely.</div><div><br></div><div><div>You could say =
the same for <font face=3D"Courier">operator*</font>; it exists for an=
int resource but using it results in an ill-formed implicit specialization=
.. This also has the effect of making the class impossible to explicitly ins=
tantiate, which may be a real issue.</div></div><div><br></div><div>Require=
ment lists avoid the over-specification tendency of informative declaration=
s. It would be better never to mention operator-> and operator* by name =
at all, perhaps by introduction of a Dereferenceable concept.</div><div><br=
></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" 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=_9D055DBC-1E26-4D3B-A898-5BB13B3BFFFC--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 15:28:24 +0800
Raw View
--Apple-Mail=_9B3EEB7F-2DEB-40B4-A006-D02555D23A9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 2:07 PM, vadim.petrochenkov@gmail.com wrote:
> What do you think about this proposal and its future? Template parameter =
deduction for constructors
It looks awesome, of course. The most obvious question is, why wasn't that =
done 15-20 years ago?
Apparently it's still on track: http://wg21.cmeerw.net/ewg/issue60 , althou=
gh that also provides a troubling answer to my question:
> Core pointed out problems in Bristol. Gregor summarized in Chicago 2013 =
that The primary template might not be the right place to pick constructors=
from. (Partial) specializations might have completely different constructo=
rs. Stroustrup thought that there's only two ways: all specializations have=
to be in scope, and you look at all of those, or look only at the primary =
and give an error if that doesn't work. Spertus is encouraged to write a fo=
llow-up paper.
>=20
I'm not sure how you would go about looking at all specializations, includi=
ng partial ones. The template parameters of a partial specialization are ge=
nerated by the parameters of the primary; they cannot be deduced from a fun=
ction argument.
That leads to a problem with things like std::function where the primary te=
mplate is just a dummy. Yikes. You'd have to do deduction and overload reso=
lution according to the constructor signature in the primary template, then=
check for a non-primary specialization, and if one is found then redo over=
load resolution.
--=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=_9B3EEB7F-2DEB-40B4-A006-D02555D23A9A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 2:07 PM, <a href=3D"mailto:vadim.petrochenkov@gmail.com">vadim.p=
etrochenkov@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newlin=
e"><blockquote type=3D"cite"><div dir=3D"ltr">What do you think about this =
proposal and its future? <a href=3D"http://open-std.org/JTC1/SC22/WG21=
/docs/papers/2013/n3602.html" style=3D"font-size: 16px; line-height: 24px; =
font-family: 'Times New Roman';">Template parameter deduction for construct=
ors</a><br></div></blockquote></div><br><div>It looks awesome, of course. T=
he most obvious question is, why wasn’t that done 15-20 years ago?</d=
iv><div><br></div><div>Apparently it’s still on track: <a href=3D"htt=
p://wg21.cmeerw.net/ewg/issue60">http://wg21.cmeerw.net/ewg/issue60</a> , a=
lthough that also provides a troubling answer to my question:</div><div><bl=
ockquote type=3D"cite"><span class=3D"msg"><p> Core pointed out proble=
ms in Bristol. Gregor summarized in Chicago 2013=20
that
The primary template might not be the right place to pick constructors=20
from. (Partial) specializations might have completely different=20
constructors.=20
Stroustrup thought that there's only two ways: all specializations have=20
to be=20
in scope, and you look at all of those, or look only at the primary and=20
give=20
an error if that doesn't work. Spertus is encouraged to write a=20
follow-up=20
paper.</p></span></blockquote></div><div>I’m not sure how you would g=
o about looking at all specializations, including partial ones. The templat=
e parameters of a partial specialization are generated by the parameters of=
the primary; they cannot be deduced from a function argument.</div><div><b=
r></div><div>That leads to a problem with things like <font face=3D"Courier=
">std::function</font> where the primary template is just a dummy. Yik=
es. You’d have to do deduction and overload resolution according to t=
he constructor signature in the primary template, then check for a non-prim=
ary specialization, and if one is found then redo overload resolution.</div=
><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 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 />
--Apple-Mail=_9B3EEB7F-2DEB-40B4-A006-D02555D23A9A--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 3 Mar 2014 09:37:06 +0200
Raw View
On 3 March 2014 09:08, David Krauss <potswa@gmail.com> wrote:
>> I don't think such iterators should have such an operator->.
>> [iterator.requirements.general]/1 says
>> "All iterators i for which the expression (*i).m is well-defined, support
>> the
>> expression i->m with the same semantics as (*i).m. "
>> For the iterators in case here, (*i).m is not well-defined, so they
>> shouldn't
>> support operator->.
> The standard simply doesn't discuss the implementation of iterator
> operator->. It does not require the function to exist, but neither does it
> forbid it, and it's such a minor QOI issue that nobody cares. SFINAE is just
Yes, what the quoted passage say doesn't really define whether the operator
is or is not there, unfortunately.
> a hoop to jump through here, and it makes implementation bugs more likely.
Implementations have to perform such "does not participate in overload
resolution"
conditioning in so many places that this is a non-issue. Weighing the pointless
presence of a certainly-ill-formed operator versus the implementation
complexity,
I'd say the restrictions for operator-> and operator* are just fine,
and should be
specified correctly.
> You could say the same for operator*; it exists for an int resource but
> using it results in an ill-formed implicit specialization. This also has the
Except that it doesn't exist for an int resource according to the
current proposal.
> effect of making the class impossible to explicitly instantiate, which may
> be a real issue.
All the more reason to avoid always-ill-formed member functions.
Thus far I've heard zero good reasons to include them unconditionally.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 3 Mar 2014 16:04:36 +0800
Raw View
--Apple-Mail=_F6AE20E0-436E-4BB4-9491-3C67D74F4B32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 3, 2014, at 3:37 PM, Ville Voutilainen <ville.voutilainen@gmail.com>=
wrote:
> Implementations have to perform such "does not participate in overload
> resolution" conditioning in so many places that this is a non-issue.
It gets easier with practice, but "non-issue" is a bit optimistic. New libr=
ary features often take a while to stabilize.
> I'd say the restrictions for operator-> and operator* are just fine,
> and should be
> specified correctly.
What are the restrictions intended to be? Complexity isn't purely an implem=
entation issue. Earlier I said that operator-> is probably supposed to chec=
k is_pointer || is_class || is_union, but looking closer it seems they were=
shooting for pointer to class or union, which excludes smart pointers. Sur=
e, naked pointers are the motivating case, but why shouldn't the classes co=
ntinue to work if you plug in something else? Not attempting to litigate ev=
ery detail allows such things to "just work" by default.
>> You could say the same for operator*; it exists for an int resource but
>> using it results in an ill-formed implicit specialization. This also has=
the
>=20
> Except that it doesn't exist for an int resource according to the
> current proposal.
Ah, I was relying on the "example implementation" and neglected to look at =
the actual spec. Woops.
If the SFINAE had been fleshed out in the prototype, we wouldn't be having =
this discussion now...
--=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=_F6AE20E0-436E-4BB4-9491-3C67D74F4B32
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 3=
, 2014, at 3:37 PM, Ville Voutilainen <<a href=3D"mailto:ville.voutilain=
en@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite">Implementations have t=
o perform such "does not participate in overload<br>resolution” =
conditioning in so many places that this is a non-issue. </blockquote><div>=
<br></div><div>It gets easier with practice, but “non-issue” is=
a bit optimistic. New library features often take a while to stabilize.</d=
iv><br><blockquote type=3D"cite">I'd say the restrictions for operator->=
and operator* are just fine,<br>and should be<br>specified correctly.<br><=
/blockquote><div><br></div><div>What are the restrictions intended to be? C=
omplexity isn't purely an implementation issue. Earlier I said that <font f=
ace=3D"Courier">operator-></font> is probably supposed to check <font fa=
ce=3D"Courier">is_pointer || is_class || is_union</font>, but looking close=
r it seems they were shooting for pointer <i>to</i> class or union, wh=
ich excludes smart pointers. Sure, naked pointers are the motivating case, =
but why shouldn’t the classes continue to work if you plug in somethi=
ng else? Not attempting to litigate every detail allows such things to &ldq=
uo;just work” by default.</div><br><blockquote type=3D"cite"><blockqu=
ote type=3D"cite">You could say the same for operator*; it exists for an in=
t resource but<br>using it results in an ill-formed implicit specialization=
.. This also has the<br></blockquote><br>Except that it doesn't exist for an=
int resource according to the<br>current proposal.<br></blockquote><div><b=
r></div><div>Ah, I was relying on the “example implementation” =
and neglected to look at the actual spec. Woops.</div><div><br></div><div>I=
f the SFINAE had been fleshed out in the prototype, we wouldn’t be ha=
ving this discussion now…</div><div><br></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" 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 />
--Apple-Mail=_F6AE20E0-436E-4BB4-9491-3C67D74F4B32--
.
Author: Peter Sommerlad <peter.sommerlad@hsr.ch>
Date: Mon, 3 Mar 2014 16:49:25 +0100
Raw View
Hi Ville,
thank you for your feedback....
On 02.03.2014, at 13:31, Ville Voutilainen <ville.voutilainen@gmail.com> wr=
ote:
> 1) I find it odd that scope_guard_t is moveconstructible.
Well, how would you then define a factory for it? I believe a function retu=
rn requires either moveconstructable or copyconstructable. Therefore I prov=
ided the move constructor but prohibited anything else. If someone really w=
ants to move further out of a function scope, OK with me.
> QScopedPointer
> isn't, boost::scoped_ptr isn't.
Do they have a factory? or is the deleter type part of their type signature=
?
> If this type is designed to live in one scope
> and not move out of it, it should not be movable, since that allows
> moving it into and out of scopes. If it is designed to be moved into
> and out of scopes, I don't think its name is good.
Any other solution I could conceive would require macros or type erasure of=
the deleter type, which both come at a cost I didn't want to pay.
>=20
> 2) minor nit: the deleted copy assignment operator for scope_guard_t
> is void operator=3D(scope_guard_t const &)=3Ddelete;, the return type
> is void, which is not the usual canonical form. =20
but less to type. (Peter S. and Kevlin H.: "Less Code =3D=3D More Software"=
)
> The move assignment
> operator isn't deleted, but it doesn't have to be since it will be suppre=
ssed.
> I would recommend explicitly deleting all copy/move operations
> explicitly, so that implementations give better diagnostics.
I consider that quality of implementation. void as return type was chosen f=
or brevity.
>=20
> 3) I find the naming of the types and factory functions inconsistent
> with the rest of the standard. This proposal uses scope_guard_t and
> unique_resource_t as the types, and scope_guard and unique_resource(_chec=
ked)
> as the factory functions. I'd find it more consistent to have scope_guard
> and unique_resource as the types and make_scope_guard and
> make_unique_resource(_checked) as the factories. Sure, they are
> longer to type, but they would be consistent.
There is a subtle difference in semantics, e.g., make_unique/make_shared ac=
tually allocate a resource, whereas neither scope_guard nor unique_resource=
do so. In addition, I made the choice to name the factory functions to be =
easy to remember. May be even the type names used for scope_guard_t or uniq=
ue_resource_t can be made opaque, because one would never spell them out an=
yway reasonably, or can not even do so, when lambdas are involved.
>=20
> 4) unique_resource::operator-> is specified as
> R operator->() const noexcept ;
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
>=20
> I think this is a bit inconsistent with how library usually specifies
> such SFINAE-conditional overloads. It's usually a Remark, so
> I think this should be
> <del>
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
> </del>
> <ins>
> Remarks:
> This function shall not participate in overload resolution unless
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
> is true.
> </ins>
>=20
> We certainly don't want to have it as Requires, since usually violating
> a Requires-clause results in undefined behavior. Same issue with
> operator*,
>=20
> see below operator*() const noexcept;
> <del>
> Requires:
> This function is only available if
> is_pointer<R>::value is true.
> </del>
> <ins>
> Remarks:
> This function shall not participate in overload resolution unless
> is_pointer<R>::value is true.
> </ins>
>=20
Yes, thank you, I intended to adjust that but forgot it. I will update it f=
or the pre-Rapperswil mailing accordingly.
> 5) unique_resource::get_deleter is specified as
> const DELETER & get_deleter() const noexcept;
> but the name of the template parameter is D, so
> this should now be
>=20
> const D& get_deleter() const noexcept;
OOPS, missed the change. That happens, when you don't have live-links to th=
e code from latex.
>=20
>=20
>=20
> I think the proposal is otherwise ok. :)
Thank you for your blessing :-)
Regards
Peter.
--=20
Prof. Peter Sommerlad
Institut f=FCr Software: Bessere Software - Einfach, Schneller!
HSR Hochschule f=FCr Technik Rapperswil
Oberseestr 10, Postfach 1475, CH-8640 Rapperswil
http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includa=
tor.com
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/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 03 Mar 2014 12:01:48 -0500
Raw View
On 2014-03-03 10:49, Peter Sommerlad wrote:
> On 02.03.2014, at 13:31, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> 1) I find it odd that scope_guard_t is moveconstructible.
>
> Well, how would you then define a factory for it? I believe a
> function return requires either moveconstructable or
> copyconstructable. Therefore I provided the move constructor but
> prohibited anything else. If someone really wants to move further out
> of a function scope, OK with me.
What if I want to write a function that creates a resource, does
something with it, then returns it to the caller for further use. Does
that not also require that the resource wrapper is move constructible?
Should this use be forbidden?
(IOW maybe being move-constructible is actually desirable?)
std::unique_ptr is also move-constructible unless I am mistaken?
>> QScopedPointer isn't, boost::scoped_ptr isn't.
>
> Do they have a factory? or is the deleter type part of their type
> signature?
The deleter is a template parameter of QScopedPointer. See e.g.
http://qt-project.org/doc/qt-5/qscopedpointer.html.
--
Matthew
--
---
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 3 Mar 2014 19:19:04 +0200
Raw View
On 3 March 2014 17:49, Peter Sommerlad <peter.sommerlad@hsr.ch> wrote:
>> 1) I find it odd that scope_guard_t is moveconstructible.
> Well, how would you then define a factory for it? I believe a function re=
turn requires either moveconstructable or copyconstructable. Therefore I pr=
ovided the move constructor but prohibited anything else. If someone really=
wants to move further out of a function scope, OK with me.
Yeah, David Krauss already pointed this out. I can't imagine a way around i=
t.
>> 2) minor nit: the deleted copy assignment operator for scope_guard_t
>> is void operator=3D(scope_guard_t const &)=3Ddelete;, the return type
>> is void, which is not the usual canonical form.
> but less to type. (Peter S. and Kevlin H.: "Less Code =3D=3D More Softwar=
e")
Ok.
>>
>> 3) I find the naming of the types and factory functions inconsistent
>> with the rest of the standard. This proposal uses scope_guard_t and
>> unique_resource_t as the types, and scope_guard and unique_resource(_che=
cked)
>> as the factory functions. I'd find it more consistent to have scope_guar=
d
>> and unique_resource as the types and make_scope_guard and
>> make_unique_resource(_checked) as the factories. Sure, they are
>> longer to type, but they would be consistent.
>
> There is a subtle difference in semantics, e.g., make_unique/make_shared =
actually allocate a resource, whereas neither scope_guard nor unique_resour=
ce do so. In addition, I made the choice to name the factory functions to b=
e easy to remember. May be even the type names used for scope_guard_t or un=
ique_resource_t can be made opaque, because one would never spell them out =
anyway reasonably, or can not even do so, when lambdas are involved.
Even with that subtle difference, I would still prefer the factory
functions being make_unique_resource
and make_scope_guard. The current factory function looks like a type.
>> I think the proposal is otherwise ok. :)
> Thank you for your blessing :-)
You're welcome. :)
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 3 Mar 2014 19:20:32 +0200
Raw View
On 3 March 2014 19:01, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2014-03-03 10:49, Peter Sommerlad wrote:
>> Well, how would you then define a factory for it? I believe a
>> function return requires either moveconstructable or
>> copyconstructable. Therefore I provided the move constructor but
>> prohibited anything else. If someone really wants to move further out
>> of a function scope, OK with me.
> What if I want to write a function that creates a resource, does something
> with it, then returns it to the caller for further use. Does that not also
> require that the resource wrapper is move constructible? Should this use be
> forbidden?
I have no problem with unique_resource being movable. I don't like scope_guard
being movable.
--
---
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/.
.
Author: Geoffrey Romer <gromer@google.com>
Date: Mon, 3 Mar 2014 11:05:37 -0800
Raw View
--047d7beb961e0f1d0004f3b8798e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Mar 2, 2014 at 7:48 AM, David Krauss <potswa@gmail.com> wrote:
>
> On Mar 2, 2014, at 8:31 PM, Ville Voutilainen <ville.voutilainen@gmail.co=
m>
> wrote:
>
> 1) I find it odd that scope_guard_t is moveconstructible. QScopedPointer
> isn't, boost::scoped_ptr isn't. If this type is designed to live in one
> scope
> and not move out of it, it should not be movable, since that allows
> moving it into and out of scopes. If it is designed to be moved into
> and out of scopes, I don't think its name is good.
>
>
> I think this is an artifact of the requirement that its type must be
> deduced by a factory function, unlike those other utilities.
>
> The pattern for a factory function of an immovable type is to use
> copy-list-initialization, and declare the local object as a universal
> reference. See my StackOverflow Q&A, Correctly implement finally block
> using C++ lambda <http://stackoverflow.com/q/17356258/153285>.
>
>
> 3) I find the naming of the types and factory functions inconsistent
> with the rest of the standard.
>
>
> The proposal notes that this is because the guard isn=E2=80=99t supposed =
to be
> treated as an object.
>
> IMHO, =E2=80=9Cscope_guard=E2=80=9D names a =E2=80=9Cthing,=E2=80=9D whic=
h is awkward for a function, and
> it's a C++-specific buzzword which is not descriptive about what it does
> for the program. For what it=E2=80=99s worth, my personal utility is call=
ed
> finally (as you can see in the above SO link).
>
>
> 4) unique_resource::operator-> is specified as
> R operator->() const noexcept ;
> Requires:
> operator->
> is only available if
> is_pointer<R>::value && (is_class<R>::value || is_union<R>::value)
>
>
> R can=E2=80=99t simultaneously be a pointer and class. Perhaps it's suppo=
sed to be
>
> is_pointer<R>::value || is_class<R>::value || is_union<R>::value
>
> I think this is a bit inconsistent with how library usually specifies
> such SFINAE-conditional overloads. It's usually a Remark, so
> I think this should be
>
>
> What=E2=80=99s the point of the restriction anyway? R will seldom if ever=
be
> anything besides a pointer or class, and the operator-> definition is
> well-formed for any copyable R. (Non-copyable objects are always classes
> anyway.)
>
>
> 6) The bool execute_on_destruction member is an unnecessary expense for
> the many use cases that don=E2=80=99t need release (which itself is an
> anti-pattern). It=E2=80=99s not much, but it will affect a lot of code in=
cluding
> inner loops.
>
> When I need release, I just capture a local flag and use it within the
> guard.
>
> bool keep_input =3D false;
> auto && guard =3D finally( [&]() noexcept {
> if ( ! keep_input ) input.clear();
> } );
>
> If the library will support release specially, perhaps it should be
> factored into a generic one-shot functor utility.
>
>
> 7) scope_guard encapsulates the contained functor, but it=E2=80=99s not r=
eally an
> adaptor. How about making the deleter member public and calling it invoke=
?
> This would avoid hiding the user=E2=80=99s own object. With a generic one=
-shot
> functor, instead of guard.release() we would have guard.invoke.cancel() w=
hich
> is still pretty self-explanatory.
>
>
> 8) Most compilers warn about unused variables, and a guard will never be
> mentioned after its declaration unless it=E2=80=99s released somewhere. T=
here
> should be a provision for touching the guard, such as a no-op member
> function. Perhaps call it exiting. The name should reveal that the given
> guard is being =E2=80=9Cclosed=E2=80=9D but shouldn=E2=80=99t imply that =
the call is what is
> closing it. In my library, it=E2=80=99s a macro named DO_FINALLY but I do=
n=E2=80=99t
> suppose that macros go over well in the std lib :) .
>
std::mutex_lock doesn't do this, so I see no reason for this library to.
Can you substantiate the "most compilers" claim? I'm familiar with errors
on unused variables of trivial types, but to warn on unused variables when
construction and destruction have side effects seems like a monumental
misfeature. It would surprise me if this were as widespread as you say
(doubly so if this warning can't just be turned off), but even if it was,
adding a feature to the standard library solely to enable client code to
work around defective implementations would be the tail wagging the dog.
>
>
> 9) Perhaps this has been debated, but the requirement =E2=80=9CD shall no=
t throw
> an exception=E2=80=9D could be strengthened to =E2=80=9CD shall be noexce=
pt.=E2=80=9D See the
> above StackOverflow link. Ultimately this only requires the user to add t=
he
> noexcept keyword, but there may be value in that. Or, if proven to have
> no benefit, the requirement could be relaxed by a later standard revision=
..
>
What benefit would imposing this requirement have?
>
>
> --
>
> ---
> 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/.
>
--=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/.
--047d7beb961e0f1d0004f3b8798e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Mar 2, 2014 at 7:48 AM, David Krauss <span dir=3D"ltr"><<a h=
ref=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>><=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div><div>On Mar 2, 2014, at 8:31 PM, Ville Voutilainen <<a href=3D"mai=
lto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.=
com</a>> wrote:</div>
<br><blockquote type=3D"cite">1) I find it odd that scope_guard_t is moveco=
nstructible. QScopedPointer<br>isn't, boost::scoped_ptr isn't. If t=
his type is designed to live in one scope<br>and not move out of it, it sho=
uld not be movable, since that allows<br>
moving it into and out of scopes. If it is designed to be moved into<br>and=
out of scopes, I don't think its name is good.<br></blockquote><div><b=
r></div></div><div>I think this is an artifact of the requirement that its =
type must be deduced by a factory function, unlike those other utilities.</=
div>
<div><br></div><div>The pattern for a factory function of an immovable type=
is to use copy-list-initialization, and declare the local object as a univ=
ersal reference. See my StackOverflow Q&A,=C2=A0<a href=3D"http://stack=
overflow.com/q/17356258/153285" target=3D"_blank">Correctly implement final=
ly block using C++ lambda</a>.</div>
<div><div><br></div><div><br></div><blockquote type=3D"cite">3) I find the =
naming of the types and factory functions inconsistent<br>with the rest of =
the standard.<br></blockquote><div><br></div></div><div>The proposal notes =
that this is because the guard isn=E2=80=99t supposed to be treated as an o=
bject.</div>
<div><br></div><div>IMHO, =E2=80=9C<font face=3D"Courier">scope_guard</font=
>=E2=80=9D names a =E2=80=9Cthing,=E2=80=9D which is awkward for a function=
, and it's a C++-specific buzzword which is not descriptive about what =
it does for the program. For what it=E2=80=99s worth, my personal utility i=
s called <font face=3D"Courier">finally</font>=C2=A0(as you can see in the =
above SO link).</div>
<div><div><br></div><br><blockquote type=3D"cite">4) unique_resource::opera=
tor-> is specified as<br>R operator->() const noexcept ;<br>Requires:=
<br>operator-><br>is only available if<br>is_pointer<R>::value &am=
p;& (is_class<R>::value || is_union<R>::value)<br>
</blockquote><div><br></div></div><div>R can=E2=80=99t simultaneously be a =
pointer and class. Perhaps it's supposed to be</div><div><br></div><div=
><font face=3D"Courier">is_pointer<R>::value || is_class<R>::va=
lue || is_union<R>::value</font></div>
<div><br><blockquote type=3D"cite">I think this is a bit inconsistent with =
how library usually specifies<br>such SFINAE-conditional overloads. It'=
s usually a Remark, so<br>I think this should be<br></blockquote>
<div><br></div></div><div>What=E2=80=99s the point of the restriction anywa=
y? <font face=3D"Courier">R</font> will seldom if ever be anything besides =
a pointer or class, and the <font face=3D"Courier">operator-></font>=C2=
=A0definition is well-formed for any copyable=C2=A0<span style=3D"font-fami=
ly:Courier">R</span>. (Non-copyable objects are always classes anyway.)</di=
v>
</div><div><br></div><br><div>6) The bool <font face=3D"Courier">execute_on=
_destruction</font> member is an unnecessary expense for the many use cases=
that don=E2=80=99t need <font face=3D"Courier">release</font>=C2=A0(which =
itself is an anti-pattern). It=E2=80=99s not much, but it will affect a lot=
of code including inner loops.</div>
<div><br></div><div>When I need <font face=3D"Courier">release</font>, I ju=
st capture a local flag and use it within the guard.</div><div><br></div><d=
iv><div><font face=3D"Courier">bool keep_input =3D false;</font></div><div>=
<font face=3D"Courier">auto && guard =3D finally( [&]() noexcep=
t {</font></div>
<div><font face=3D"Courier">=C2=A0 =C2=A0 if ( !=C2=A0</font><span style=3D=
"font-family:Courier">keep_input</span><font face=3D"Courier">=C2=A0) input=
..clear();</font></div><div><font face=3D"Courier">} );</font></div></div><d=
iv><br></div><div>If the library will support <font face=3D"Courier">releas=
e</font> specially, perhaps it should be factored into a generic one-shot f=
unctor utility.</div>
<div><br></div><div><br></div><div>7) <font face=3D"Courier">scope_guard</f=
ont>=C2=A0encapsulates the contained functor, but it=E2=80=99s not really a=
n adaptor. How about making the <font face=3D"Courier">deleter</font>=C2=A0=
member public and calling it <font face=3D"Courier">invoke</font>? This wou=
ld avoid hiding the user=E2=80=99s own object. With a generic one-shot func=
tor, instead of=C2=A0<font face=3D"Courier">guard.release()</font>=C2=A0we =
would have <font face=3D"Courier">guard.invoke.cancel()</font>=C2=A0which i=
s still pretty self-explanatory.</div>
<div><br></div><div><br></div><div>8) Most compilers warn about unused vari=
ables, and a guard will never be mentioned after its declaration unless it=
=E2=80=99s released somewhere. There should be a provision for touching the=
guard, such as a no-op member function. Perhaps call it <font face=3D"Cour=
ier">exiting</font>. The name should reveal that the given guard is being =
=E2=80=9Cclosed=E2=80=9D but shouldn=E2=80=99t imply that the call is what =
is closing it. In my library, it=E2=80=99s a macro named <font face=3D"Cour=
ier">DO_FINALLY</font>=C2=A0but I don=E2=80=99t suppose that macros go over=
well in the std lib :) .</div>
</div></blockquote><div><br>std::mutex_lock doesn't do this, so I see n=
o reason for this library to.</div><div><br></div><div>Can you substantiate=
the "most compilers" claim? I'm familiar with errors on unus=
ed variables of trivial types, but to warn on unused variables when constru=
ction and destruction have side effects seems like a monumental misfeature.=
It would surprise me if this were as widespread as you say (doubly so if t=
his warning can't just be turned off), but even if it was, adding a fea=
ture to the standard library solely to enable client code to work around de=
fective implementations would be the tail wagging the dog.</div>
<div>=C2=A0</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><br></div><div><br></div><div>9) Perhaps this has been debate=
d, but the requirement =E2=80=9C<font face=3D"Courier">D</font> shall not t=
hrow an exception=E2=80=9D could be strengthened to =E2=80=9C<font face=3D"=
Courier">D</font> shall be <font face=3D"Courier">noexcept</font>.=E2=80=9D=
See the above StackOverflow link. Ultimately this only requires the user t=
o add the=C2=A0<span style=3D"font-family:Courier">noexcept</span>=C2=A0key=
word, but there may be value in that. Or, if proven to have no benefit, the=
requirement could be relaxed by a later standard revision.</div>
</div></blockquote><div><br></div><div>What benefit would imposing this req=
uirement have?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div st=
yle=3D"word-wrap:break-word">
<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" 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" target=3D"_=
blank">std-proposals+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>
<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 />
--047d7beb961e0f1d0004f3b8798e--
.
Author: Adam Nevraumont <afn@theorem.ca>
Date: Mon, 3 Mar 2014 18:44:31 -0800 (PST)
Raw View
That looks messy, in that inverting constructor types to class type is actually as complex as class writers want it to be. Doing it automatically seems fragile.
template<typename...Args>
auto operator auto template bob(Args&&... args){
return bob<std::decay_t<Args>...>(std::forward<Args>(args)...);
}
Used like:
bob<auto> b(1,2.0,'c');
which invokes operator auto template bob with the constructor argumemts.
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 4 Mar 2014 10:44:45 +0800
Raw View
--Apple-Mail=_DB895D84-076A-4CF5-A117-905EE7D4B5B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 4, 2014, at 3:05 AM, Geoffrey Romer <gromer@google.com> wrote:
> Can you substantiate the "most compilers" claim?
Testing now with the code from that StackOverflow post, Clang 3.3 (from Xco=
de) and GCC 4.8 warn with -Wall. GCC 4.9 does not. EDG (ICC 13 on godbolt.o=
rg) warns with -Wunused. However, this data is from my utility, which is no=
t moveable and uses lifetime extension by reference binding.
So the warning technically applies to the reference, which is not itself a =
named variable. However, the old ScopeGuard worked the same way so this is =
the status quo.
> I'm familiar with errors on unused variables of trivial types, but to war=
n on unused variables when construction and destruction have side effects s=
eems like a monumental misfeature.
Most non-trivial types have object-like semantics, and their instances do n=
ot justify their existence merely by being constructed and destroyed. Scope=
guards are a very special case.
> It would surprise me if this were as widespread as you say (doubly so if =
this warning can't just be turned off),
Turning off the unused variable warning is out of the question.
> but even if it was, adding a feature to the standard library solely to en=
able client code to work around defective implementations would be the tail=
wagging the dog.
It's just a no-op, and it's not really "enabling." The other workaround is =
to cast the guard to void. Personally, I generate guards by a macro, which =
could do the cast to void at the point of declaration. But, I prefer to add=
it where the guard is going out of scope. This makes it explicitly look li=
ke the cleanup code is getting "called" from the point of destruction, whic=
h is positive self-documentation.
> 9) Perhaps this has been debated, but the requirement "D shall not throw =
an exception" could be strengthened to "D shall be noexcept." See the above=
StackOverflow link. Ultimately this only requires the user to add the noex=
cept keyword, but there may be value in that. Or, if proven to have no bene=
fit, the requirement could be relaxed by a later standard revision.
>=20
> What benefit would imposing this requirement have?
It exposes the semantics to the implementation.
--=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=_DB895D84-076A-4CF5-A117-905EE7D4B5B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 4=
, 2014, at 3:05 AM, Geoffrey Romer <<a href=3D"mailto:gromer@google.com"=
>gromer@google.com</a>> wrote:</div><br class=3D"Apple-interchange-newli=
ne"><blockquote type=3D"cite"><div dir=3D"ltr">Can you substantiate the "mo=
st compilers" claim?</div></blockquote><div><br></div><div>Testing now with=
the code from that StackOverflow post, Clang 3.3 (from Xcode) and GCC 4.8 =
warn with -Wall. GCC 4.9 does not. EDG (ICC 13 on <a href=3D"http://godbolt=
..org">godbolt.org</a>) warns with -Wunused. However, this data is from my u=
tility, which is not moveable and uses lifetime extension by reference bind=
ing.</div><div><br></div><div>So the warning technically applies to the ref=
erence, which is not itself a named variable. However, the old ScopeGuard w=
orked the same way so this is the status quo.</div><div><br></div><div><blo=
ckquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">I'm familiar with errors on unused variables of trivial t=
ypes, but to warn on unused variables when construction and destruction hav=
e side effects seems like a monumental misfeature.</div></div></div></block=
quote><br></div><div>Most non-trivial types have object-like semantics, and=
their instances do not justify their existence merely by being constructed=
and destroyed. Scope guards are a very special case.</div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><div>It would surprise me if this were as widespread as you say (=
doubly so if this warning can't just be turned off), </div></div></div></di=
v></blockquote><div><br></div><div>Turning off the unused variable warning =
is out of the question.</div><br><blockquote type=3D"cite"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>but even if it =
was, adding a feature to the standard library solely to enable client code =
to work around defective implementations would be the tail wagging the dog.=
</div></div></div></div></blockquote><div><br></div><div>It’s just a =
no-op, and it’s not really “enabling.” The other workarou=
nd is to cast the guard to void. Personally, I generate guards by a macro, =
which <i>could</i> do the cast to void at the point of declaration. But, I =
prefer to add it where the guard is going out of scope. This makes it expli=
citly look like the cleanup code is getting “called” from the p=
oint of destruction, which is positive self-documentation.</div><br><blockq=
uote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style=
: solid; padding-left: 1ex; position: static; z-index: auto;"><div style=3D=
"word-wrap:break-word"><div>9) Perhaps this has been debated, but the requi=
rement “<font face=3D"Courier">D</font> shall not throw an exception&=
rdquo; could be strengthened to “<font face=3D"Courier">D</font> shal=
l be <font face=3D"Courier">noexcept</font>.” See the above StackOver=
flow link. Ultimately this only requires the user to add the <span sty=
le=3D"font-family: Courier;">noexcept</span> keyword, but there may be=
value in that. Or, if proven to have no benefit, the requirement could be =
relaxed by a later standard revision.</div>
</div></blockquote><div><br></div><div>What benefit would imposing this req=
uirement have?</div></div></div></div></blockquote><div><br></div><div>It e=
xposes the semantics to the implementation.</div></div><br></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=_DB895D84-076A-4CF5-A117-905EE7D4B5B3--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 4 Mar 2014 11:02:34 +0800
Raw View
On Mar 4, 2014, at 10:44 AM, Adam Nevraumont <afn@theorem.ca> wrote:
> That looks messy, in that inverting constructor types to class type is ac=
tually as complex as class writers want it to be. Doing it automatically s=
eems fragile.
>=20
> template<typename...Args>
> auto operator auto template bob(Args&&... args){
> return bob<std::decay_t<Args>...>(std::forward<Args>(args)...);
> }
> Used like:
> bob<auto> b(1,2.0,'c');
> which invokes operator auto template bob with the constructor arguments.
"auto operator auto template" looks a bit verbose and scary. If this is sup=
posed to be a member, why not just co-opt the explicit instantiation syntax=
and use "template"? It it's not supposed to be a member, note that templat=
e names cannot hide or be hidden by other names declared in the same scope.
Unfortunately, this proposes a special form of factory function, and factor=
ies are almost always inferior to constructors because copy/move elision is=
never guaranteed.
You can "guarantee copy elision" by returning a braced-init-list, and bindi=
ng the result to a reference, as in my scope guard implementation. I person=
ally find this quite practical and make it a habit, and I haven't found a d=
ownside yet, but it seems to have been poo-poohed here.
I don't think naming a factory after the class it generates is a problem th=
at needs solving.
--=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/.
.
Author: Adam N <notayakk@gmail.com>
Date: Mon, 3 Mar 2014 22:28:43 -0500
Raw View
--001a11344a3e45fdc804f3bf8013
Content-Type: text/plain; charset=ISO-8859-1
It is not a member: it is the free operator auto template bob.
It cannot be a member, because members exist inside classes, and class
templates produce classes. Code that deduces which instance of the class
template to create cannot reasonably be inside any of the classes.
While it looks like a bog standard factory function, it actually does not
have to be. I would make it syntax to deduce what bob<auto> gets as its
template argument. The return value could be the actual deduced variable
(forced elision). Or we could mess with the body, or even do away with it!
Doing away with it might be best. Then only the return type matters: the
operator auto template bob is never called, but overload resolution is
performed and the return type (which *must* be an instantiation of the
template class bob) is extracted, the type placeholder bob<auto> is
replaced, then the constructor called directly.
That would work, I think.
On Mar 3, 2014 10:02 PM, "David Krauss" <potswa@gmail.com> wrote:
>
> On Mar 4, 2014, at 10:44 AM, Adam Nevraumont <afn@theorem.ca> wrote:
>
> > That looks messy, in that inverting constructor types to class type is
> actually as complex as class writers want it to be. Doing it automatically
> seems fragile.
> >
> > template<typename...Args>
> > auto operator auto template bob(Args&&... args){
> > return bob<std::decay_t<Args>...>(std::forward<Args>(args)...);
> > }
> > Used like:
> > bob<auto> b(1,2.0,'c');
> > which invokes operator auto template bob with the constructor arguments.
>
> "auto operator auto template" looks a bit verbose and scary. If this is
> supposed to be a member, why not just co-opt the explicit instantiation
> syntax and use "template"? It it's not supposed to be a member, note that
> template names cannot hide or be hidden by other names declared in the same
> scope.
>
> Unfortunately, this proposes a special form of factory function, and
> factories are almost always inferior to constructors because copy/move
> elision is never guaranteed.
>
> You can "guarantee copy elision" by returning a braced-init-list, and
> binding the result to a reference, as in my scope guard implementation. I
> personally find this quite practical and make it a habit, and I haven't
> found a downside yet, but it seems to have been poo-poohed here.
>
> I don't think naming a factory after the class it generates is a problem
> that needs solving.
>
> --
>
> ---
> 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/Om0fMEJnvcM/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/.
--001a11344a3e45fdc804f3bf8013
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">It is not a member: it is the free operator auto template bo=
b.</p>
<p dir=3D"ltr">It cannot be a member, because members exist inside classes,=
and class templates produce classes.=A0 Code that deduces which instance o=
f the class template to create cannot reasonably be inside any of the class=
es.</p>
<p dir=3D"ltr">While it looks like a bog standard factory function, it actu=
ally does not have to be.=A0 I would make it syntax to deduce what bob<a=
uto> gets as its template argument.=A0 The return value could be the act=
ual deduced variable (forced elision).=A0 Or we could mess with the body, o=
r even do away with it!</p>
<p dir=3D"ltr">Doing away with it might be best.=A0 Then only the return ty=
pe matters: the operator auto template bob is never called, but overload re=
solution is performed and the return type (which *must* be an instantiation=
of the template class bob) is extracted, the type placeholder bob<auto&=
gt; is replaced, then the constructor called directly.</p>
<p dir=3D"ltr">That would work, I think.</p>
<div class=3D"gmail_quote">On Mar 3, 2014 10:02 PM, "David Krauss"=
; <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>> wrote:<b=
r type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Mar 4, 2014, at 10:44 AM, Adam Nevraumont <<a href=3D"mailto:afn@theo=
rem.ca">afn@theorem.ca</a>> wrote:<br>
<br>
> That looks messy, in that inverting constructor types to class type is=
actually as complex as class writers want it to be. =A0Doing it automatica=
lly seems fragile.<br>
><br>
> template<typename...Args><br>
> auto operator auto template bob(Args&&... args){<br>
> =A0return bob<std::decay_t<Args>...>(std::forward<Args&=
gt;(args)...);<br>
> }<br>
> Used like:<br>
> bob<auto> b(1,2.0,'c');<br>
> which invokes operator auto template bob with the constructor argument=
s.<br>
<br>
"auto operator auto template" looks a bit verbose and scary. If t=
his is supposed to be a member, why not just co-opt the explicit instantiat=
ion syntax and use "template"? It it's not supposed to be a m=
ember, note that template names cannot hide or be hidden by other names dec=
lared in the same scope.<br>
<br>
Unfortunately, this proposes a special form of factory function, and factor=
ies are almost always inferior to constructors because copy/move elision is=
never guaranteed.<br>
<br>
You can "guarantee copy elision" by returning a braced-init-list,=
and binding the result to a reference, as in my scope guard implementation=
.. I personally find this quite practical and make it a habit, and I haven&#=
39;t found a downside yet, but it seems to have been poo-poohed here.<br>
<br>
I don't think naming a factory after the class it generates is a proble=
m that needs solving.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/Om0fMEJnvcM/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/Om0fMEJnvcM=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--001a11344a3e45fdc804f3bf8013--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 04 Mar 2014 11:10:45 -0500
Raw View
On 2014-03-02 10:48, David Krauss wrote:
> 8) Most compilers warn about unused variables,
To be clear, are we talking about e.g.:
some_resource r1{...};
....or e.g.:
auto&& r1 = acquire_resource(...);
....?
AFAIK the former does *not* warn. (I use such constructs a lot in my own
code and can't say I've seen warnings. I *am* using -Wall, -Wextra and
-Wunused.)
It makes some sense that the latter would warn. It might be useful to
have an attribute that could annotate at some level (probably an
attribute of the class type itself rather than e.g. a function return)
when the compiler should not warn about an object that is "unused"
except for its dtor side effects. Then compilers could also be
encouraged to add an additional warning (i.e. not enabled by any
currently existing warning flag or by default) for any such non-use,
including the first case.
--
Matthew
--
---
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/.
.
Author: Andrew Sandoval <sandoval@netwaysglobal.com>
Date: Tue, 4 Mar 2014 10:40:32 -0600
Raw View
--001a11c129ca10ae2604f3ca9073
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 4, 2014 at 10:10 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:
> On 2014-03-02 10:48, David Krauss wrote:
>
>> 8) Most compilers warn about unused variables,
>>
>
> To be clear, are we talking about e.g.:
>
> some_resource r1{...};
>
> ...or e.g.:
>
> auto&& r1 = acquire_resource(...);
>
> ...?
>
> AFAIK the former does *not* warn. (I use such constructs a lot in my own
> code and can't say I've seen warnings. I *am* using -Wall, -Wextra and
> -Wunused.)
>
> It makes some sense that the latter would warn. It might be useful to have
> an attribute that could annotate at some level (probably an attribute of
> the class type itself rather than e.g. a function return) when the compiler
> should not warn about an object that is "unused" except for its dtor side
> effects. Then compilers could also be encouraged to add an additional
> warning (i.e. not enabled by any currently existing warning flag or by
> default) for any such non-use, including the first case.
>
> --
> Matthew
>
> How would this be different from unique_ptr or make_unique? I'm assuming
the same issues of an unused (but managed) pointer exist there too, do they
not? (Don't get me wrong, I think it would be great to have the compiler
be able to detect this -- I just think it should be a separate issue from
N3949.)
Thanks,
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/.
--001a11c129ca10ae2604f3ca9073
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 4, 2014 at 10:10 AM, Matthew Woehlke <span dir=3D"ltr"><<a href=
=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">mw_triad@users=
..sourceforge.net</a>></span> wrote:<br>
<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-l=
eft-style:solid"><div>On 2014-03-02 10:48, David Krauss wrote:<br>
<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-l=
eft-style:solid">
8) Most compilers warn about unused variables,<br>
</blockquote>
<br></div>
To be clear, are we talking about e.g.:<br>
<br>
=A0 =A0some_resource r1{...};<br>
<br>
....or e.g.:<br>
<br>
=A0 auto&& r1 =3D acquire_resource(...);<br>
<br>
....?<br>
<br>
AFAIK the former does *not* warn. (I use such constructs a lot in my own co=
de and can't say I've seen warnings. I *am* using -Wall, -Wextra an=
d -Wunused.)<br>
<br>
It makes some sense that the latter would warn. It might be useful to have =
an attribute that could annotate at some level (probably an attribute of th=
e class type itself rather than e.g. a function return) when the compiler s=
hould not warn about an object that is "unused" except for its dt=
or side effects. Then compilers could also be encouraged to add an addition=
al warning (i.e. not enabled by any currently existing warning flag or by d=
efault) for any such non-use, including the first case.<span class=3D"HOEnZ=
b"><font color=3D"#888888"><br>
<br>
-- <br>
Matthew</font></span><div class=3D"HOEnZb"><br></div></blockquote><div>How =
would this be different from unique_ptr or make_unique?=A0 I'm assuming=
the same issues of an unused (but managed) pointer exist there too, do the=
y not?=A0 (Don't get me wrong, I think it would be great to have the co=
mpiler be able to detect this -- I just think it should be a separate issue=
from N3949.)</div>
<div><br></div><div>Thanks,</div><div>Andrew Sandoval</div><div>=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" 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 />
--001a11c129ca10ae2604f3ca9073--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 5 Mar 2014 08:57:10 +0800
Raw View
--Apple-Mail=_02C12725-7F15-4EEF-9B77-B9310068AD69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On Mar 5, 2014, at 12:10 AM, Matthew Woehlke <mw_triad@users.sourceforge.ne=
t> wrote:
> On 2014-03-02 10:48, David Krauss wrote:
>> 8) Most compilers warn about unused variables,
>=20
> To be clear, are we talking about e.g.:
>=20
> some_resource r1{...};
>=20
> ...or e.g.:
>=20
> auto&& r1 =3D acquire_resource(...);
>=20
> ...?
>=20
> AFAIK the former does *not* warn. (I use such constructs a lot in my own =
code and can't say I've seen warnings. I *am* using -Wall, -Wextra and -Wun=
used.)
Yes, the reference does make a difference, unless your compiler happens to =
be GCC 4.9. (I didn't check bleeding-edge Clang though.) I took the warning=
as an invitation to annotate the usual location of guard invocation.
So, disabling the warning isn't a big implementation issue (GCC already did=
it), and a documentation-only no-op is useful even without a QOI quirk as =
an impetus.
> It makes some sense that the latter would warn. It might be useful to hav=
e an attribute that could annotate at some level (probably an attribute of =
the class type itself rather than e.g. a function return) when the compiler=
should not warn about an object that is "unused" except for its dtor side =
effects. Then compilers could also be encouraged to add an additional warni=
ng (i.e. not enabled by any currently existing warning flag or by default) =
for any such non-use, including the first case.
For guards, it would make sense to forbid an object from being a temporary,=
so folks doing forget add auto <unique-id>! I'm a bit surprised this isn't=
mentioned more often. Sticking a ref-qualifier on the constructor or destr=
uctor has been mentioned a few times, though, for various applications.
Even better would be not to require that a guard specification be a formal =
declaration. A dedicated keyword (final?) could be used to introduce a "dec=
laration" with a missing type or declarator, adding auto && or <unique-id> =
as necessary. Since only certain types are intended for use as guards, the =
keyword might only work for classes decorated with a similar specifier.
final std::lock_guard< std::mutex >( m ); // missing identifier
final make_scope_guard( []{ std::cout << "exiting\n"; } ); // missing type =
and identifier
final transaction =3D make_scope_guard( & cleanup ); // missing type
--=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=_02C12725-7F15-4EEF-9B77-B9310068AD69
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 5=
, 2014, at 12:10 AM, Matthew Woehlke <<a href=3D"mailto:mw_triad@users.s=
ourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</div><br clas=
s=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 2014-03-02 10:=
48, David Krauss wrote:<br><blockquote type=3D"cite">8) Most compilers warn=
about unused variables,<br></blockquote><br>To be clear, are we talking ab=
out e.g.:<br><br> some_resource r1{...};<br><br>...or e.g.:<br>=
<br> auto&& r1 =3D acquire_resource(...);<br><br>...?<br><br>=
AFAIK the former does *not* warn. (I use such constructs a lot in my own co=
de and can't say I've seen warnings. I *am* using -Wall, -Wextra and -Wunus=
ed.)<br></blockquote><div><br></div><div><div>Yes, the reference does make =
a difference, unless your compiler happens to be GCC 4.9. (I didn’t c=
heck bleeding-edge Clang though.) I took the warning as an invitation to an=
notate the usual location of guard invocation.</div><div><br></div><div>So,=
disabling the warning isn't a big implementation issue (GCC already did it=
), and a documentation-only no-op is useful even without a QOI quirk as an =
impetus.</div></div><br><blockquote type=3D"cite">It makes some sense that =
the latter would warn. It might be useful to have an attribute that could a=
nnotate at some level (probably an attribute of the class type itself rathe=
r than e.g. a function return) when the compiler should not warn about an o=
bject that is "unused" except for its dtor side effects. Then compilers cou=
ld also be encouraged to add an additional warning (i.e. not enabled by any=
currently existing warning flag or by default) for any such non-use, inclu=
ding the first case.<br></blockquote><div><br></div><div>For guards, it wou=
ld make sense to forbid an object from being a temporary, so folks doing fo=
rget add <font face=3D"Courier">auto </font><unique-id>! I&rsquo=
;m a bit surprised this isn’t mentioned more often. Sticking a ref-qu=
alifier on the constructor or destructor has been mentioned a few times, th=
ough, for various applications.</div><div><br></div><div>Even better would =
be not to require that a guard specification be a formal declaration. A ded=
icated keyword (<span style=3D"font-family: Courier;">final</span>?) c=
ould be used to introduce a “declaration” with a missing type o=
r declarator, adding <font face=3D"Courier">auto &&</font>&nbs=
p;or <unique-id> as necessary. Since only certain types are intended =
for use as guards, the keyword might only work for classes decorated with a=
similar specifier.</div><div><br></div><div><font face=3D"Courier">final s=
td::lock_guard< std::mutex >( m ); // missing identifier</font></div>=
<div><font face=3D"Courier"><br></font></div><div><font face=3D"Courier">fi=
nal make_scope_guard( []{ std::cout << “exiting\n”; } ); =
// missing type and identifier</font></div><div><br></div><div><div><font f=
ace=3D"Courier">final transaction =3D make_scope_guard( & cleanup ); //=
missing type</font></div><div><br></div></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" 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=_02C12725-7F15-4EEF-9B77-B9310068AD69--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 05 Mar 2014 11:37:08 -0500
Raw View
On 2014-03-04 19:57, David Krauss wrote:
> Even better would be not to require that a guard specification be a
> formal declaration. A dedicated keyword (final?) could be used to
> introduce a "declaration" with a missing type or declarator, adding
> auto && or <unique-id> as necessary. Since only certain types are
> intended for use as guards, the keyword might only work for classes
> decorated with a similar specifier.
>
> final std::lock_guard< std::mutex >( m ); // missing identifier
>
> final make_scope_guard( []{ std::cout << "exiting\n"; } ); // missing type and identifier
I like this idea! In fact I think I'd said something about wanting this
a while ago :-). Having to come up with identifier names for guards that
are never used except for their ctor and/or dtor side effects is
annoying and in no way helps code readability.
Unfortunately, making 'final' a full keyword might break existing code.
For example, the following is legal (if ugly) in C++11:
struct final {};
struct bar {};
int foo()
{
final bar{}; // declares a 'struct final' named 'bar'
}
> final transaction = make_scope_guard( & cleanup ); // missing type
I'm not sure this form is needed, however; what's the difference between
this and 'auto&& transaction = ...'? (If the above are available but
you've chosen to name the variable anyway, to me that implies that you
are going to reference it as well.)
I suppose there's no harm though...
--
Matthew
--
---
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/.
.