Topic: [propagate_const] Why not copyable by non-const reference?
Author: joseph.thomson@gmail.com
Date: Wed, 17 Feb 2016 02:42:02 -0800 (PST)
Raw View
------=_Part_1897_561295342.1455705722823
Content-Type: multipart/alternative;
boundary="----=_Part_1898_819683839.1455705722823"
------=_Part_1898_819683839.1455705722823
Content-Type: text/plain; charset=UTF-8
The proposed propagate_const class template seems like great news for
const-correctness and thread-safety, but it seems that the fact that it
isn't copyable means that any class with a propagate_const data member can
*never* be copyable (in most sane situations). User-defined copy operations
don't even help.
struct foo
{
propagate_const<int*> value;
foo(int* v) : value(v) {}
foo(foo const& other) : value( /* uh...? */ ) {}
};
I understand that copying by const reference can violate const-correctness,
but can't propagate_const support copying by non-const reference? AFAIK,
the compiler will even generate default non-const copy operations for if a
class has data members which have non-const copy operations.
struct foo
{
propagate_const<int*> value;
};
foo f(foo const& value)
{
return value; // error
}
foo g(foo& value)
{
return value; // legal
}
Am I missing something here?
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1898_819683839.1455705722823
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The proposed <span style=3D"font-family: courier new,monos=
pace;">propagate_const</span> class template seems like great news for cons=
t-correctness and thread-safety, but it seems that the fact that it isn'=
;t copyable means that any class with a <span style=3D"font-family: courier=
new,monospace;">propagate_const</span> data member can <b><i>never</i></b>=
be copyable (in most sane situations). User-defined copy operations don=
9;t even help.<br><br><div style=3D"margin-left: 40px;"><span style=3D"colo=
r: rgb(32, 18, 77);"><span style=3D"font-family: courier new,monospace;">st=
ruct foo</span><br><span style=3D"font-family: courier new,monospace;">{</s=
pan><br><span style=3D"font-family: courier new,monospace;">=C2=A0=C2=A0=C2=
=A0 propagate_const<int*> value;</span><br><span style=3D"font-family=
: courier new,monospace;"></span><br><span style=3D"font-family: courier ne=
w,monospace;">=C2=A0=C2=A0=C2=A0 foo(int* v) : value(v) {}</span><br><span =
style=3D"font-family: courier new,monospace;">=C2=A0=C2=A0=C2=A0 foo(foo co=
nst& other) : value( /* uh...? */ ) {}</span><br><span style=3D"font-fa=
mily: courier new,monospace;">};</span></span><br></div><br>I understand th=
at copying by const reference can violate const-correctness, but can't =
<span style=3D"font-family: courier new,monospace;">propagate_const</span> =
support copying by non-const reference? AFAIK, the compiler will even gener=
ate default non-const copy operations for if a class has data members which=
have non-const copy operations.<br><br><div style=3D"margin-left: 40px;"><=
span style=3D"color: rgb(32, 18, 77);"><span style=3D"font-family: courier =
new,monospace;">struct foo</span><br><span style=3D"font-family: courier ne=
w,monospace;">{</span><br><span style=3D"font-family: courier new,monospace=
;">=C2=A0=C2=A0=C2=A0 propagate_const<int*> value;</span><br><span st=
yle=3D"font-family: courier new,monospace;">};</span><br><span style=3D"fon=
t-family: courier new,monospace;"></span><br><span style=3D"font-family: co=
urier new,monospace;">foo f(foo const& value)</span><br><span style=3D"=
font-family: courier new,monospace;">{</span><br><span style=3D"font-family=
: courier new,monospace;">=C2=A0=C2=A0=C2=A0 return value; // error</span><=
br><span style=3D"font-family: courier new,monospace;">}</span><br><span st=
yle=3D"font-family: courier new,monospace;"></span><br><span style=3D"font-=
family: courier new,monospace;">foo g(foo& value)</span><br><span style=
=3D"font-family: courier new,monospace;">{</span><br><span style=3D"font-fa=
mily: courier new,monospace;">=C2=A0=C2=A0=C2=A0 return value; // legal</sp=
an><br><span style=3D"font-family: courier new,monospace;">}</span></span><=
br></div><br>Am I missing something here?<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_1898_819683839.1455705722823--
------=_Part_1897_561295342.1455705722823--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 17 Feb 2016 13:07:41 +0200
Raw View
On 17 February 2016 at 12:42, <joseph.thomson@gmail.com> wrote:
> The proposed propagate_const class template seems like great news for
> const-correctness and thread-safety, but it seems that the fact that it
> isn't copyable means that any class with a propagate_const data member can
> never be copyable (in most sane situations). User-defined copy operations
> don't even help.
>
> struct foo
> {
> propagate_const<int*> value;
>
> foo(int* v) : value(v) {}
> foo(foo const& other) : value( /* uh...? */ ) {}
> };
>
> I understand that copying by const reference can violate const-correctness,
> but can't propagate_const support copying by non-const reference? AFAIK, the
> compiler will even generate default non-const copy operations for if a class
> has data members which have non-const copy operations.
You can copy from a reference-to-nonconst propagate_const<int*> thus:
int x = 42;
std::experimental::propagate_const<int*> pc{&x};
std::experimental::propagate_const<int*> pc2{pc.get()};
and if you know what you're doing, you can copy from a reference-to-const:
const std::experimental::propagate_const<int*> pc3{pc.get()};
std::experimental::propagate_const<int*> pc4{get_underlying(pc3)};
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: joseph.thomson@gmail.com
Date: Wed, 17 Feb 2016 03:27:17 -0800 (PST)
Raw View
------=_Part_6980_687827772.1455708437695
Content-Type: multipart/alternative;
boundary="----=_Part_6981_652605748.1455708437695"
------=_Part_6981_652605748.1455708437695
Content-Type: text/plain; charset=UTF-8
It's good to know there is a safe workaround. Is there a reason
propagate_const doesn't define non-const copy operations?
On Wednesday, 17 February 2016 19:07:43 UTC+8, Ville Voutilainen wrote:
>
> On 17 February 2016 at 12:42, <joseph....@gmail.com <javascript:>>
> wrote:
> > The proposed propagate_const class template seems like great news for
> > const-correctness and thread-safety, but it seems that the fact that it
> > isn't copyable means that any class with a propagate_const data member
> can
> > never be copyable (in most sane situations). User-defined copy
> operations
> > don't even help.
> >
> > struct foo
> > {
> > propagate_const<int*> value;
> >
> > foo(int* v) : value(v) {}
> > foo(foo const& other) : value( /* uh...? */ ) {}
> > };
> >
> > I understand that copying by const reference can violate
> const-correctness,
> > but can't propagate_const support copying by non-const reference? AFAIK,
> the
> > compiler will even generate default non-const copy operations for if a
> class
> > has data members which have non-const copy operations.
>
>
> You can copy from a reference-to-nonconst propagate_const<int*> thus:
>
> int x = 42;
> std::experimental::propagate_const<int*> pc{&x};
> std::experimental::propagate_const<int*> pc2{pc.get()};
>
>
> and if you know what you're doing, you can copy from a reference-to-const:
>
> const std::experimental::propagate_const<int*> pc3{pc.get()};
> std::experimental::propagate_const<int*> pc4{get_underlying(pc3)};
>
--
---
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 https://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_6981_652605748.1455708437695
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It's good to know there is a safe workaround. Is there=
a reason <span style=3D"font-family: courier new,monospace;">propagate_con=
st</span> doesn't define non-const copy operations?<br><br>On Wednesday=
, 17 February 2016 19:07:43 UTC+8, Ville Voutilainen wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;">On 17 February 2016 at 12:42, =C2=A0<<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PHEtETcbAAAJ"=
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return t=
rue;" onclick=3D"this.href=3D'javascript:';return true;">joseph....=
@gmail.com</a>> wrote:
<br>> The proposed propagate_const class template seems like great news =
for
<br>> const-correctness and thread-safety, but it seems that the fact th=
at it
<br>> isn't copyable means that any class with a propagate_const dat=
a member can
<br>> never be copyable (in most sane situations). User-defined copy ope=
rations
<br>> don't even help.
<br>>
<br>> struct foo
<br>> {
<br>> =C2=A0 =C2=A0 propagate_const<int*> value;
<br>>
<br>> =C2=A0 =C2=A0 foo(int* v) : value(v) {}
<br>> =C2=A0 =C2=A0 foo(foo const& other) : value( /* uh...? */ ) {}
<br>> };
<br>>
<br>> I understand that copying by const reference can violate const-cor=
rectness,
<br>> but can't propagate_const support copying by non-const referen=
ce? AFAIK, the
<br>> compiler will even generate default non-const copy operations for =
if a class
<br>> has data members which have non-const copy operations.
<br>
<br>
<br>You can copy from a reference-to-nonconst propagate_const<int*> t=
hus:
<br>
<br>=C2=A0 =C2=A0 int x =3D 42;
<br>=C2=A0 =C2=A0 std::experimental::propagate_<wbr>const<int*> pc{&a=
mp;x};
<br>=C2=A0 =C2=A0 std::experimental::propagate_<wbr>const<int*> pc2{p=
c.get()};
<br>
<br>
<br>and if you know what you're doing, you can copy from a reference-to=
-const:
<br>
<br>=C2=A0 =C2=A0 const std::experimental::propagate_<wbr>const<int*>=
pc3{pc.get()};
<br>=C2=A0 =C2=A0 std::experimental::propagate_<wbr>const<int*> pc4{g=
et_underlying(pc3)};
<br></blockquote><div>=C2=A0</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />
------=_Part_6981_652605748.1455708437695--
------=_Part_6980_687827772.1455708437695--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sat, 20 Feb 2016 08:13:20 +0000
Raw View
--Apple-Mail-A15E6314-D3D0-4348-AA92-514660FFAE24
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> On 17 Feb 2016, at 11:27, joseph.thomson@gmail.com wrote:
>=20
> It's good to know there is a safe workaround. Is there a reason propagate=
_const doesn't define non-const copy operations?
>=20
This was briefly discussed during design. We were not confident that a non-=
const copy constructor would protect the user from accidental loss of const=
and accidental mutable shared state. The 'get_underlying' function allows =
a user to explicitly define a copy_constructor when that is desirable.
>> On Wednesday, 17 February 2016 19:07:43 UTC+8, Ville Voutilainen wrote:
>> On 17 February 2016 at 12:42, <joseph....@gmail.com> wrote:=20
>> > The proposed propagate_const class template seems like great news for=
=20
>> > const-correctness and thread-safety, but it seems that the fact that i=
t=20
>> > isn't copyable means that any class with a propagate_const data member=
can=20
>> > never be copyable (in most sane situations). User-defined copy operati=
ons=20
>> > don't even help.=20
>> >=20
>> > struct foo=20
>> > {=20
>> > propagate_const<int*> value;=20
>> >=20
>> > foo(int* v) : value(v) {}=20
>> > foo(foo const& other) : value( /* uh...? */ ) {}=20
>> > };=20
>> >=20
>> > I understand that copying by const reference can violate const-correct=
ness,=20
>> > but can't propagate_const support copying by non-const reference? AFAI=
K, the=20
>> > compiler will even generate default non-const copy operations for if a=
class=20
>> > has data members which have non-const copy operations.=20
>>=20
>>=20
>> You can copy from a reference-to-nonconst propagate_const<int*> thus:=20
>>=20
>> int x =3D 42;=20
>> std::experimental::propagate_const<int*> pc{&x};=20
>> std::experimental::propagate_const<int*> pc2{pc.get()};=20
>>=20
>>=20
>> and if you know what you're doing, you can copy from a reference-to-cons=
t:=20
>>=20
>> const std::experimental::propagate_const<int*> pc3{pc.get()};=20
>> std::experimental::propagate_const<int*> pc4{get_underlying(pc3)};
> =20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at https://groups.google.com/a/isocpp.org/group/std-prop=
osals/.
--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/B668EEA4-23BB-481C-9524-4BC29D30F374%40gmail.com=
..
--Apple-Mail-A15E6314-D3D0-4348-AA92-514660FFAE24
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div></div><div><br></div><div><br>On 1=
7 Feb 2016, at 11:27, <a href=3D"mailto:joseph.thomson@gmail.com">joseph.th=
omson@gmail.com</a> wrote:<br><br></div><blockquote type=3D"cite"><div><div=
dir=3D"ltr">It's good to know there is a safe workaround. Is there a reaso=
n <span style=3D"font-family: courier new,monospace;">propagate_const</span=
> doesn't define non-const copy operations?<br><br></div></div></blockquote=
><div><br></div><div>This was briefly discussed during design. We were not =
confident that a non-const copy constructor would protect the user from acc=
idental loss of const and accidental mutable shared state. The 'get_underly=
ing' function allows a user to explicitly define a copy_constructor when th=
at is desirable.</div><br><blockquote type=3D"cite"><div><div dir=3D"ltr">O=
n Wednesday, 17 February 2016 19:07:43 UTC+8, Ville Voutilainen wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On 17 February 2016 at 12:42, &nbs=
p;<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PH=
EtETcbAAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">joseph....@gmai=
l.com</a>> wrote:
<br>> The proposed propagate_const class template seems like great news =
for
<br>> const-correctness and thread-safety, but it seems that the fact th=
at it
<br>> isn't copyable means that any class with a propagate_const data me=
mber can
<br>> never be copyable (in most sane situations). User-defined copy ope=
rations
<br>> don't even help.
<br>>
<br>> struct foo
<br>> {
<br>> propagate_const<int*> value;
<br>>
<br>> foo(int* v) : value(v) {}
<br>> foo(foo const& other) : value( /* uh...? */ ) {}
<br>> };
<br>>
<br>> I understand that copying by const reference can violate const-cor=
rectness,
<br>> but can't propagate_const support copying by non-const reference? =
AFAIK, the
<br>> compiler will even generate default non-const copy operations for =
if a class
<br>> has data members which have non-const copy operations.
<br>
<br>
<br>You can copy from a reference-to-nonconst propagate_const<int*> t=
hus:
<br>
<br> int x =3D 42;
<br> std::experimental::propagate_<wbr>const<int*> pc{&a=
mp;x};
<br> std::experimental::propagate_<wbr>const<int*> pc2{p=
c.get()};
<br>
<br>
<br>and if you know what you're doing, you can copy from a reference-to-con=
st:
<br>
<br> const std::experimental::propagate_<wbr>const<int*>=
pc3{pc.get()};
<br> std::experimental::propagate_<wbr>const<int*> pc4{g=
et_underlying(pc3)};
<br></blockquote><div> </div></div>
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br>
</div></blockquote></body></html>
<p></p>
-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/B668EEA4-23BB-481C-9524-4BC29D30F374%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/B668EEA4-23BB-481C-9524-4BC29D30F374%=
40gmail.com</a>.<br />
--Apple-Mail-A15E6314-D3D0-4348-AA92-514660FFAE24--
.