Topic: Ref-qualified destructors for expression
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 24 Sep 2013 18:40:15 -0700
Raw View
On ter=E7a-feira, 24 de setembro de 2013 18:22:45, David Krauss wrote:
> A ref-qualified derived destructor should call the corresponding base=20
> destructor, obviously. Qualified destructors need to be implicitly define=
d=20
> to make that happen in general. I think the rule should be that presence =
of=20
> a qualified destructor in the base triggers implicit declaration in the
> derived class, and then declaring an unqualified destructor would be an
> illegal overload.
>=20
> I see no reason not to allow one destructor to be virtual and the other=
=20
> non-virtual. You can ref-qualify overload any member function and make it=
=20
> virtual for just one value category of this. Rather cruel to the user, bu=
t=20
> not a special case of language semantics.
I'm wondering if you shouldn't ref-qualify the constructor instead of the=
=20
destructor. Constructors can't be virtual. Even if it's not the case, we=20
should explore the possibility of ref-qualifying constructors.
Also, what happens to deletes? Suppose you have:
struct Foo
{
~Foo() & =3D delete;
~Foo() && =3D default;
};
When you do:
Foo *p =3D get_from_somewhere();
delete p;
p and *p are lvalues, so I guess the deletion is disallowed. What happens i=
f=20
you do:
delete std::move(*p);
Would this now be allowed? I would guess so.
I'm also wondering if this is useful to cause compiler errors where we toda=
y=20
use GCC's __attribute__((required_result)).
How about lifetime extension of temporaries:
struct Bar
{
~Bar() & =3D default;
~Bar() && =3D delete;
};
void f()
{
Bar(); // not allowed
const Bar &b =3D Bar(); // allowed?
}
If the above is allowed, then the function declaration:
Bar g();
should be allowed, because it might be used as
const Bar &b =3D g();
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Tue, 24 Sep 2013 19:08:19 -0700
Raw View
--089e0118470a890f4804e72bbc34
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
>I'm wondering if you shouldn't ref-qualify the constructor instead of the
destructor. Constructors can't be virtual. Even if it's not the case, we
should explore the possibility of ref-qualifying constructors.
What would that even mean? There's no syntax at the call site to say that
you want the object constructed "as an rvalue".
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Tue, Sep 24, 2013 at 6:40 PM, Thiago Macieira <thiago@macieira.org>wrote=
:
> On ter=E7a-feira, 24 de setembro de 2013 18:22:45, David Krauss wrote:
> > A ref-qualified derived destructor should call the corresponding base
> > destructor, obviously. Qualified destructors need to be implicitly
> defined
> > to make that happen in general. I think the rule should be that presenc=
e
> of
> > a qualified destructor in the base triggers implicit declaration in the
> > derived class, and then declaring an unqualified destructor would be an
> > illegal overload.
> >
> > I see no reason not to allow one destructor to be virtual and the other
> > non-virtual. You can ref-qualify overload any member function and make =
it
> > virtual for just one value category of this. Rather cruel to the user,
> but
> > not a special case of language semantics.
>
> I'm wondering if you shouldn't ref-qualify the constructor instead of the
> destructor. Constructors can't be virtual. Even if it's not the case, we
> should explore the possibility of ref-qualifying constructors.
>
> Also, what happens to deletes? Suppose you have:
>
> struct Foo
> {
> ~Foo() & =3D delete;
> ~Foo() && =3D default;
> };
>
> When you do:
> Foo *p =3D get_from_somewhere();
> delete p;
>
> p and *p are lvalues, so I guess the deletion is disallowed. What happens
> if
> you do:
>
> delete std::move(*p);
>
> Would this now be allowed? I would guess so.
>
> I'm also wondering if this is useful to cause compiler errors where we
> today
> use GCC's __attribute__((required_result)).
>
> How about lifetime extension of temporaries:
>
> struct Bar
> {
> ~Bar() & =3D default;
> ~Bar() && =3D delete;
> };
>
> void f()
> {
> Bar(); // not allowed
> const Bar &b =3D Bar(); // allowed?
> }
>
> If the above is allowed, then the function declaration:
> Bar g();
>
> should be allowed, because it might be used as
> const Bar &b =3D g();
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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/.
--089e0118470a890f4804e72bbc34
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>I'm wondering if you shouldn't ref-qualif=
y the constructor instead of the<br> destructor. Constructors can't be =
virtual. Even if it's not the case, we<br> should explore the possibili=
ty of ref-qualifying constructors.</div>
<div class=3D"gmail_extra">=A0</div><div class=3D"gmail_extra">What would t=
hat even mean? There's no syntax at the call site to say that you want =
the object constructed "as an rvalue".<br clear=3D"all"></div><di=
v class=3D"gmail_extra">
<div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Tue, Sep 24, 2013 at 6:40 PM, Thiago =
Macieira <span dir=3D"ltr"><<a href=3D"mailto:thiago@macieira.org" targe=
t=3D"_blank">thiago@macieira.org</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-left-style:solid">
<div class=3D"im">On ter=E7a-feira, 24 de setembro de 2013 18:22:45, David =
Krauss wrote:<br>
> A ref-qualified derived destructor should call the corresponding base<=
br>
> destructor, obviously. Qualified destructors need to be implicitly def=
ined<br>
> to make that happen in general. I think the rule should be that presen=
ce of<br>
> a qualified destructor in the base triggers implicit declaration in th=
e<br>
> derived class, and then declaring an unqualified destructor would be a=
n<br>
> illegal overload.<br>
><br>
> I see no reason not to allow one destructor to be virtual and the othe=
r<br>
> non-virtual. You can ref-qualify overload any member function and make=
it<br>
> virtual for just one value category of this. Rather cruel to the user,=
but<br>
> not a special case of language semantics.<br>
<br>
</div>I'm wondering if you shouldn't ref-qualify the constructor in=
stead of the<br>
destructor. Constructors can't be virtual. Even if it's not the cas=
e, we<br>
should explore the possibility of ref-qualifying constructors.<br>
<br>
Also, what happens to deletes? Suppose you have:<br>
<br>
struct Foo<br>
{<br>
=A0 =A0 ~Foo() & =3D delete;<br>
=A0 =A0 ~Foo() && =3D default;<br>
};<br>
<br>
When you do:<br>
=A0 =A0 =A0 =A0 Foo *p =3D get_from_somewhere();<br>
=A0 =A0 =A0 =A0 delete p;<br>
<br>
p and *p are lvalues, so I guess the deletion is disallowed. What happens i=
f<br>
you do:<br>
<br>
=A0 =A0 =A0 =A0 delete std::move(*p);<br>
<br>
Would this now be allowed? I would guess so.<br>
<br>
I'm also wondering if this is useful to cause compiler errors where we =
today<br>
use GCC's __attribute__((required_result)).<br>
<br>
How about lifetime extension of temporaries:<br>
<br>
struct Bar<br>
{<br>
=A0 =A0 ~Bar() & =3D default;<br>
=A0 =A0 ~Bar() && =3D delete;<br>
};<br>
<br>
void f()<br>
{<br>
=A0 =A0 Bar(); // not allowed<br>
=A0 =A0 const Bar &b =3D Bar(); // allowed?<br>
}<br>
<br>
If the above is allowed, then the function declaration:<br>
=A0 =A0 =A0 =A0 Bar g();<br>
<br>
should be allowed, because it might be used as<br>
=A0 =A0 =A0 =A0 const Bar &b =3D g();<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=A0 =A0Software Architect - Intel Open Source Technology Center<br>
=A0 =A0 =A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=A0 =A0 =A0 E067 918B B660 DBD1 105C =A0966C 33F5 F005 6EF4 5358<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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/" 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 />
--089e0118470a890f4804e72bbc34--
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 25 Sep 2013 10:12:42 +0800
Raw View
On 9/25/13 9:40 AM, Thiago Macieira wrote:
> I'm wondering if you shouldn't ref-qualify the constructor instead of
> the destructor.
See bottom of this post.
> delete std::move(*p);
>
> Would this now be allowed? I would guess so.
I guess so too. Really the uses are limited to automatic storage
duration. If this "issue" discourages someone from putting a
supposed-to-be-temporary class on the heap, then that's a good thing.
Likewise for explicit pseudo destructor calls.
> I'm also wondering if this is useful to cause compiler errors where we today
> use GCC's __attribute__((required_result)).
I couldn't find that, but did find __attribute__((warn_unused_result)).
Is that it?
Unfortunately, I don't see how this could be extended that way. This is
only a means of requiring an object be (not) named or bound to a name.
There was another thread where I suggested operator void() to do exactly
that, though. You could define a status value class, and cause ignoring
a nonzero return status to throw an exception.
> How about lifetime extension of temporaries:
>
> struct Bar
> {
> ~Bar() & = default;
> ~Bar() && = delete;
> };
>
> void f()
> {
> Bar(); // not allowed
> const Bar &b = Bar(); // allowed?
> }
>
> If the above is allowed, then the function declaration:
> Bar g();
>
> should be allowed, because it might be used as
> const Bar &b = g();
>
Yes. This is essentially why I suggested tying it to the destructor, not
the constructor. Scope guards need to work this way.
--
---
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/.
.