Topic: Should reinterpret_cast be able to cast away const?
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Wed, 22 Oct 2014 08:26:34 -0700 (PDT)
Raw View
------=_Part_210_644457672.1413991594146
Content-Type: text/plain; charset=UTF-8
No, IMO...
I'd like all such casts to be findable by searching for const_cast. I
frequently use reinterpret_cast<> but I very, very rarely use const_cast.
"This paper presents the proposed resolution for core issue 330
<http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330> as
reviewed in teleconferences of WG21's Core Working Group, substantially
cleaning up the wording around qualification converions. Other than
allowing the qualification conversions asked for in the issue, it also
changes reinterpret_cast so that it may now cast away constness."
N4178: Proposed resolution for Core Issue 330: Qualification conversions
and pointers to arrays of pointers
by Jens Maurer
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html
--
---
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_210_644457672.1413991594146
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">No, IMO...<div>I'd like all such casts to be findable by s=
earching for const_cast. I frequently use reinterpret_cast<> but I ve=
ry, very rarely use const_cast.</div><div><br></div><div><h1 style=3D"color=
: rgb(0, 0, 0); font-family: 'Times New Roman'; line-height: normal;">"<spa=
n style=3D"font-size: medium;">This paper presents the proposed resolution =
for </span><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_=
active.html#330" style=3D"font-size: medium;">core issue 330</a><span style=
=3D"font-size: medium;"> as reviewed in teleconferences of WG21's Core=
Working Group, substantially cleaning up the wording around qualification =
converions. Other than allowing the qualification conversions asked for in =
the issue, it also changes </span><code style=3D"font-size: 13px;">rei=
nterpret_cast</code><span style=3D"font-size: medium;"> so that it may=
now cast away constness."</span></h1><div><br></div><h1 style=3D"color: rg=
b(0, 0, 0); font-family: 'Times New Roman'; line-height: normal;">N4178: Pr=
oposed resolution for Core Issue 330: Qualification conversions and pointer=
s to arrays of pointers</h1></div><div>by <span style=3D"color: rgb(0,=
0, 0); font-family: 'Times New Roman'; font-size: medium;">Jens Maurer</sp=
an></div><div><div><br></div><div>http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2014/n4178.html<br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_210_644457672.1413991594146--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 23 Oct 2014 05:29:20 -0700 (PDT)
Raw View
------=_Part_621_1106342666.1414067360046
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Wednesday, 22 October 2014 16:26:34 UTC+1, Olaf van der Spek wrote:=20
>
> No, IMO...=20
> I'd like all such casts to be findable by searching for const_cast. I=20
> frequently use reinterpret_cast<> but I very, very rarely use const_cast.
>
> =20
>
FWIW, I agree=E2=80=A6 I consider const_casting should not be hidden in a=
=20
reinterpret_cast. Removing a cv-qualifier would make me wonder why it was=
=20
there in the first place.
--=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/.
------=_Part_621_1106342666.1414067360046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><BR>On Wednesday, 22 October 2014 16:26:34 UTC+1, Olaf van=
der Spek wrote:=20
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>No, IMO...=20
<DIV>I'd like all such casts to be findable by searching for const_cast. I =
frequently use reinterpret_cast<> but I very, very rarely use const_c=
ast.</DIV>
<DIV><BR> </DIV></DIV></BLOCKQUOTE>
<DIV>FWIW, I agree=E2=80=A6 I consider const_casting should not be hidden i=
n a reinterpret_cast. Removing a cv-qualifier would make me wonder wh=
y it was there in the first place.</DIV></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_621_1106342666.1414067360046--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 22 Oct 2014 14:12:14 -0700 (PDT)
Raw View
------=_Part_23_65244425.1414012334232
Content-Type: text/plain; charset=UTF-8
On Wednesday, October 22, 2014 8:26:34 AM UTC-7, Olaf van der Spek wrote:
>
> No, IMO...
> I'd like all such casts to be findable by searching for const_cast. I
> frequently use reinterpret_cast<> but I very, very rarely use const_cast.
>
> "This paper presents the proposed resolution for core issue 330
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330> as
> reviewed in teleconferences of WG21's Core Working Group, substantially
> cleaning up the wording around qualification converions. Other than
> allowing the qualification conversions asked for in the issue, it also
> changes reinterpret_cast so that it may now cast away constness."
>
> N4178: Proposed resolution for Core Issue 330: Qualification conversions
> and pointers to arrays of pointers
> by Jens Maurer
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html
>
/sign
It seems dangerous to allow reinterpret_cast to remove constness.
reinterpret_cast is dangerous enough; why make it even more dangerous? In
addition, const-correctness is something that can be preserved even if you
are doing something otherwise crazy.
I think that the const changes in the paper other than with
reinterpret_cast are fine. However, I also think that any reform of the
pointer-to-array rules ought to include fixing unknown-size arrays so that
you can convert from a known-sized array to an unknown-sized array.
BTW, that paper has a typo: "converions".
Melissa
--
---
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_23_65244425.1414012334232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, October 22, 2014 8:26:34 AM UTC-7, Olaf van =
der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">No, IMO...<div>I'd like all such casts to be findable by searching for co=
nst_cast. I frequently use reinterpret_cast<> but I very, very rarely=
use const_cast.</div><div><br></div><div><h1 style=3D"color:rgb(0,0,0);fon=
t-family:'Times New Roman';line-height:normal">"<span style=3D"font-size:me=
dium">This paper presents the proposed resolution for </span><a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330" style=
=3D"font-size:medium" target=3D"_blank" onmousedown=3D"this.href=3D'http://=
www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2=
Fdocs%2Fcwg_active.html%23330\46sa\75D\46sntz\0751\46usg\75AFQjCNGxpRYAMs_H=
tL8fKOMfNjx463ADbg';return true;" onclick=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcw=
g_active.html%23330\46sa\75D\46sntz\0751\46usg\75AFQjCNGxpRYAMs_HtL8fKOMfNj=
x463ADbg';return true;">core issue 330</a><span style=3D"font-size:medium">=
as reviewed in teleconferences of WG21's Core Working Group, substant=
ially cleaning up the wording around qualification converions. Other than a=
llowing the qualification conversions asked for in the issue, it also chang=
es </span><code style=3D"font-size:13px">reinterpret_cast</code><span =
style=3D"font-size:medium"> so that it may now cast away constness."</=
span></h1><div><br></div><h1 style=3D"color:rgb(0,0,0);font-family:'Times N=
ew Roman';line-height:normal">N4178: Proposed resolution for Core Issue 330=
: Qualification conversions and pointers to arrays of pointers</h1></div><d=
iv>by <span style=3D"color:rgb(0,0,0);font-family:'Times New Roman';fo=
nt-size:medium">Jens Maurer</span></div><div><div><br></div><div><a href=3D=
"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn417=
8.html\46sa\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhkDAoMNJtymTbkA';ret=
urn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4178.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhkDAoMNJtymTbkA';return t=
rue;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n41=
78.html</a><br></div></div></div></blockquote><div><br>/sign<br><br>It seem=
s dangerous to allow <span style=3D"font-family: courier new,monospace;">re=
interpret_cast</span> to remove <span style=3D"font-family: courier new,mon=
ospace;">const</span>ness. <span style=3D"font-family: courier new,mo=
nospace;">reinterpret_cast</span> is dangerous enough; why make it even mor=
e dangerous? In addition, <span style=3D"font-family: courier new,mon=
ospace;">const</span>-correctness is something that can be preserved even i=
f you are doing something otherwise crazy.<br><br>I think that the <span st=
yle=3D"font-family: courier new,monospace;">const</span> changes in the pap=
er other than with reinterpret_cast are fine. However, I also think t=
hat any reform of the pointer-to-array rules ought to include fixing unknow=
n-size arrays so that you can convert from a known-sized array to an unknow=
n-sized array.<br><br>BTW, that paper has a typo: "converions".<br><br>Meli=
ssa<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_23_65244425.1414012334232--
.
Author: Michael Bruck <bruck.michael@gmail.com>
Date: Wed, 22 Oct 2014 12:20:22 -0700 (PDT)
Raw View
------=_Part_1_771780705.1414005622046
Content-Type: text/plain; charset=UTF-8
I agree that this should not be mixed.
Michael
On Wednesday, October 22, 2014 5:26:34 PM UTC+2, Olaf van der Spek wrote:
>
> No, IMO...
> I'd like all such casts to be findable by searching for const_cast. I
> frequently use reinterpret_cast<> but I very, very rarely use const_cast.
>
> "This paper presents the proposed resolution for core issue 330
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330> as
> reviewed in teleconferences of WG21's Core Working Group, substantially
> cleaning up the wording around qualification converions. Other than
> allowing the qualification conversions asked for in the issue, it also
> changes reinterpret_cast so that it may now cast away constness."
>
> N4178: Proposed resolution for Core Issue 330: Qualification conversions
> and pointers to arrays of pointers
> by Jens Maurer
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html
>
--
---
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_1_771780705.1414005622046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I agree that this should not be mixed.<div><br></div><div>=
Michael<br><br>On Wednesday, October 22, 2014 5:26:34 PM UTC+2, Olaf van de=
r Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
No, IMO...<div>I'd like all such casts to be findable by searching for cons=
t_cast. I frequently use reinterpret_cast<> but I very, very rarely u=
se const_cast.</div><div><br></div><div><h1 style=3D"color:rgb(0,0,0);font-=
family:'Times New Roman';line-height:normal">"<span style=3D"font-size:medi=
um">This paper presents the proposed resolution for </span><a href=3D"=
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330" style=3D"f=
ont-size:medium" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs=
%2Fcwg_active.html%23330\46sa\75D\46sntz\0751\46usg\75AFQjCNGxpRYAMs_HtL8fK=
OMfNjx463ADbg';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_act=
ive.html%23330\46sa\75D\46sntz\0751\46usg\75AFQjCNGxpRYAMs_HtL8fKOMfNjx463A=
Dbg';return true;">core issue 330</a><span style=3D"font-size:medium"> =
;as reviewed in teleconferences of WG21's Core Working Group, substantially=
cleaning up the wording around qualification converions. Other than allowi=
ng the qualification conversions asked for in the issue, it also changes&nb=
sp;</span><code style=3D"font-size:13px">reinterpret_cast</code><span style=
=3D"font-size:medium"> so that it may now cast away constness."</span>=
</h1><div><br></div><h1 style=3D"color:rgb(0,0,0);font-family:'Times New Ro=
man';line-height:normal">N4178: Proposed resolution for Core Issue 330: Qua=
lification conversions and pointers to arrays of pointers</h1></div><div>by=
<span style=3D"color:rgb(0,0,0);font-family:'Times New Roman';font-si=
ze:medium">Jens Maurer</span></div><div><div><br></div><div><a href=3D"http=
://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html" target=3D"_=
blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4178.htm=
l\46sa\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhkDAoMNJtymTbkA';return t=
rue;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fww=
w.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn4178.html\46s=
a\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhkDAoMNJtymTbkA';return true;"=
>http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2014/<wbr>n4178.ht=
ml</a><br></div></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1_771780705.1414005622046--
.
Author: achille@franklychat.com
Date: Wed, 22 Oct 2014 15:45:32 -0700 (PDT)
Raw View
------=_Part_57_2006072376.1414017932958
Content-Type: text/plain; charset=UTF-8
Totally agree, that's the entire purpose of const_cast and reinterpret_cast
being separated operations. If you need this behavior either use both
together or use C-style casts.
On Wednesday, October 22, 2014 8:26:34 AM UTC-7, Olaf van der Spek wrote:
>
> No, IMO...
> I'd like all such casts to be findable by searching for const_cast. I
> frequently use reinterpret_cast<> but I very, very rarely use const_cast.
>
> "This paper presents the proposed resolution for core issue 330
> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#330> as
> reviewed in teleconferences of WG21's Core Working Group, substantially
> cleaning up the wording around qualification converions. Other than
> allowing the qualification conversions asked for in the issue, it also
> changes reinterpret_cast so that it may now cast away constness."
>
> N4178: Proposed resolution for Core Issue 330: Qualification conversions
> and pointers to arrays of pointers
> by Jens Maurer
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4178.html
>
--
---
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_57_2006072376.1414017932958
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Totally agree, that's the entire purpose of const_cast and=
reinterpret_cast=20
being separated operations. If you need this behavior either use both=20
together or use C-style casts.<br><br>On Wednesday, October 22, 2014 8:26:3=
4 AM UTC-7, Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">No, IMO...<div>I'd like all such casts to be findabl=
e by searching for const_cast. I frequently use reinterpret_cast<> bu=
t I very, very rarely use const_cast.</div><div><br></div><div><h1 style=3D=
"color:rgb(0,0,0);font-family:'Times New Roman';line-height:normal">"<span =
style=3D"font-size:medium">This paper presents the proposed resolution for&=
nbsp;</span><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_acti=
ve.html#330" style=3D"font-size:medium" target=3D"_blank" onmousedown=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjt=
c1%2Fsc22%2Fwg21%2Fdocs%2Fcwg_active.html%23330\46sa\75D\46sntz\0751\46usg\=
75AFQjCNGxpRYAMs_HtL8fKOMfNjx463ADbg';return true;" onclick=3D"this.href=3D=
'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fcwg_active.html%23330\46sa\75D\46sntz\0751\46usg\75AFQjCNGx=
pRYAMs_HtL8fKOMfNjx463ADbg';return true;">core issue 330</a><span style=3D"=
font-size:medium"> as reviewed in teleconferences of WG21's Core Worki=
ng Group, substantially cleaning up the wording around qualification conver=
ions. Other than allowing the qualification conversions asked for in the is=
sue, it also changes </span><code style=3D"font-size:13px">reinterpret=
_cast</code><span style=3D"font-size:medium"> so that it may now cast =
away constness."</span></h1><div><br></div><h1 style=3D"color:rgb(0,0,0);fo=
nt-family:'Times New Roman';line-height:normal">N4178: Proposed resolution =
for Core Issue 330: Qualification conversions and pointers to arrays of poi=
nters</h1></div><div>by <span style=3D"color:rgb(0,0,0);font-family:'T=
imes New Roman';font-size:medium">Jens Maurer</span></div><div><div><br></d=
iv><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/=
n4178.html" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google=
..com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpa=
pers%2F2014%2Fn4178.html\46sa\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhk=
DAoMNJtymTbkA';return true;" onclick=3D"this.href=3D'http://www.google.com/=
url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%=
2F2014%2Fn4178.html\46sa\75D\46sntz\0751\46usg\75AFQjCNG2FymotCGMTHBhkDAoMN=
JtymTbkA';return true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/pa=
pers/2014/<wbr>n4178.html</a><br></div></div></div></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 />
------=_Part_57_2006072376.1414017932958--
.
Author: Jens Maurer <Jens.Maurer@gmx.net>
Date: Sat, 25 Oct 2014 22:42:37 +0200
Raw View
On 10/22/2014 05:26 PM, Olaf van der Spek wrote:
> No, IMO...
> I'd like all such casts to be findable by searching for const_cast. I frequently use reinterpret_cast<> but I very, very rarely use const_cast.
I'd like to point out that the prohibition works only on a subset
of reinterpret_cast cases. The following examples (by Richard Smith)
are valid today, yet remove some "const":
const int **p;
int **q = reinterpret_cast<int**>(reinterpret_cast<void*>(p));
void (X::*f)();
void (X::*g)() const = reinterpret_cast<void (X::*)() const>(f);
Anyway, I've reinstated the previous rule for reinterpret_cast,
but the wording got changed a little in doing so:
http://jmaurer.awardspace.info/wg21/proposed_resolution_core-330.html
There's still an open issue to be solved here, namely that nothing
prohibits a single P_i to stand for multiple "pointer to" levels,
where additional "consts" might be hiding.
Jens
--
---
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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 27 Oct 2014 14:29:46 +0100
Raw View
On Sat, Oct 25, 2014 at 10:42 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> On 10/22/2014 05:26 PM, Olaf van der Spek wrote:
>> No, IMO...
>> I'd like all such casts to be findable by searching for const_cast. I frequently use reinterpret_cast<> but I very, very rarely use const_cast.
>
> I'd like to point out that the prohibition works only on a subset
> of reinterpret_cast cases. The following examples (by Richard Smith)
> are valid today, yet remove some "const":
There's no technical reason to allow this removal of const by
reinterpret_cast<> is there?
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 27 Oct 2014 12:09:17 -0700
Raw View
--20cf307f37ce6a928d05066c4484
Content-Type: text/plain; charset=UTF-8
On Mon, Oct 27, 2014 at 6:29 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:
> On Sat, Oct 25, 2014 at 10:42 PM, Jens Maurer <Jens.Maurer@gmx.net> wrote:
> > On 10/22/2014 05:26 PM, Olaf van der Spek wrote:
> >> No, IMO...
> >> I'd like all such casts to be findable by searching for const_cast. I
> frequently use reinterpret_cast<> but I very, very rarely use const_cast.
> >
> > I'd like to point out that the prohibition works only on a subset
> > of reinterpret_cast cases. The following examples (by Richard Smith)
> > are valid today, yet remove some "const":
>
> There's no technical reason to allow this removal of const by
> reinterpret_cast<> is there?
Yes, there is. Consider:
struct S {
const int *p;
} s;
const int **p = &s.p;
S *q = reinterpret_cast<S*>(p);
This "removes" const in exactly the way that I did in my example, and it's
a legitimate thing to do, and is useful in some cases. Requiring a
const_cast in this case would be ridiculous.
Here's how I see it: for a reinterpret_cast between pointer types, either
(1) the result of the reinterpret_cast points to "the same object", that
is, the new pointer can be used to access the same objects as the old
pointer could. By 3.10/10, this means that the source and destination types
were similar. In this case, casting away constness should perhaps be
disallowed.
(2) the result of the reinterpret_cast points to a different object that is
known to be at the same address (for instance, casting between a
standard-layout struct and its first member, in either direction). In this
case, *only* top-level cv-qualifiers should be preserved.
(3) the result of the reinterpret_cast is not usable except by casting to
another type.
Therefore I think if we want to prohibit const_cast from casting away
constness, we should ignore the third case and say:
If T and U are similar types, a conversion from T to U casts away constness
if T and U differ and there is no qualification conversion from T to U.
Otherwise, if T is X* and U is Y*, a conversion from T to U casts away
constness if X and Y differ in their cv-qualifications and Y is not more
cv-qualified than X.
Otherwise, a conversion from T to U does not cast away constness.
--
---
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/.
--20cf307f37ce6a928d05066c4484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Oct 27, 2014 at 6:29 AM, Olaf van der Spek <span dir=3D"ltr"><<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On S=
at, Oct 25, 2014 at 10:42 PM, Jens Maurer <<a href=3D"mailto:Jens.Maurer=
@gmx.net">Jens.Maurer@gmx.net</a>> wrote:<br>
> On 10/22/2014 05:26 PM, Olaf van der Spek wrote:<br>
>> No, IMO...<br>
>> I'd like all such casts to be findable by searching for const_=
cast. I frequently use reinterpret_cast<> but I very, very rarely use=
const_cast.<br>
><br>
</span>> I'd like to point out that the prohibition works only on a =
subset<br>
> of reinterpret_cast cases.=C2=A0 The following examples (by Richard Sm=
ith)<br>
> are valid today, yet remove some "const":<br>
<br>
There's no technical reason to allow this removal of const by<br>
reinterpret_cast<> is there?</blockquote><div><br></div><div>Yes, the=
re is. Consider:</div><div><br></div><div>=C2=A0 struct S {</div><div>=C2=
=A0 =C2=A0 const int *p;</div><div>=C2=A0 } s;</div><div>=C2=A0 const int *=
*p =3D &s.p;</div><div>=C2=A0 S *q =3D reinterpret_cast<S*>(p);</=
div><div><br></div><div>This "removes" const in exactly the way t=
hat I did in my example, and it's a legitimate thing to do, and is usef=
ul in some cases. Requiring a const_cast in this case would be ridiculous.<=
/div><div><br></div><div>Here's how I see it: for a reinterpret_cast be=
tween pointer types, either</div><div><br></div><div>(1) the result of the =
reinterpret_cast points to "the same object", that is, the new po=
inter can be used to access the same objects as the old pointer could. By 3=
..10/10, this means that the source and destination types were similar. In t=
his case, casting away constness should perhaps be disallowed.<br></div><di=
v>(2) the result of the reinterpret_cast points to a different object that =
is known to be at the same address (for instance, casting between a standar=
d-layout struct and its first member, in either direction). In this case, *=
only* top-level cv-qualifiers should be preserved.</div><div>(3) the result=
of the reinterpret_cast is not usable except by casting to another type.</=
div><div><br></div><div>Therefore I think if we want to prohibit const_cast=
from casting away constness, we should ignore the third case and say:</div=
><div><br></div><div>If T and U are similar types, a conversion from T to U=
casts away constness if T and U differ and there is no qualification conve=
rsion from T to U.</div><div>Otherwise, if T is X* and U is Y*, a conversio=
n from T to U casts away constness if X and Y differ in their cv-qualificat=
ions and Y is not more cv-qualified than X.</div><div>Otherwise, a conversi=
on from T to U does not cast away constness.</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">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 />
--20cf307f37ce6a928d05066c4484--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Tue, 28 Oct 2014 14:52:42 +0100
Raw View
On Mon, Oct 27, 2014 at 8:09 PM, Richard Smith <richard@metafoo.co.uk> wrote:
>> There's no technical reason to allow this removal of const by
>> reinterpret_cast<> is there?
>
>
> Yes, there is. Consider:
>
> struct S {
> const int *p;
> } s;
> const int **p = &s.p;
> S *q = reinterpret_cast<S*>(p);
>
> This "removes" const in exactly the way that I did in my example, and it's a
> legitimate thing to do, and is useful in some cases. Requiring a const_cast
> in this case would be ridiculous.
Why would it be ridiculous?
--
---
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: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 28 Oct 2014 10:12:43 -0700
Raw View
--047d7b33db6a6524db05067ec1b9
Content-Type: text/plain; charset=UTF-8
On Tue, Oct 28, 2014 at 6:52 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:
> On Mon, Oct 27, 2014 at 8:09 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
> >> There's no technical reason to allow this removal of const by
> >> reinterpret_cast<> is there?
> >
> >
> > Yes, there is. Consider:
> >
> > struct S {
> > const int *p;
> > } s;
> > const int **p = &s.p;
> > S *q = reinterpret_cast<S*>(p);
> >
> > This "removes" const in exactly the way that I did in my example, and
> it's a
> > legitimate thing to do, and is useful in some cases. Requiring a
> const_cast
> > in this case would be ridiculous.
>
> Why would it be ridiculous?
Because the conversion is const-correct already. The const_cast would be
entirely spurious, and would be confusing and harmful to readers of the
code.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7b33db6a6524db05067ec1b9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Oct 28, 2014 at 6:52 AM, Olaf van der Spek <span dir=3D"ltr"><<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On M=
on, Oct 27, 2014 at 8:09 PM, Richard Smith <<a href=3D"mailto:richard@me=
tafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> There's no technical reason to allow this removal of const by<=
br>
>> reinterpret_cast<> is there?<br>
><br>
><br>
> Yes, there is. Consider:<br>
><br>
>=C2=A0 =C2=A0struct S {<br>
>=C2=A0 =C2=A0 =C2=A0const int *p;<br>
>=C2=A0 =C2=A0} s;<br>
>=C2=A0 =C2=A0const int **p =3D &s.p;<br>
>=C2=A0 =C2=A0S *q =3D reinterpret_cast<S*>(p);<br>
><br>
> This "removes" const in exactly the way that I did in my exa=
mple, and it's a<br>
> legitimate thing to do, and is useful in some cases. Requiring a const=
_cast<br>
> in this case would be ridiculous.<br>
<br>
</span>Why would it be ridiculous?</blockquote><div><br></div><div>Because =
the conversion is const-correct already. The const_cast would be entirely s=
purious, and would be confusing and harmful to readers of the code.</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">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 />
--047d7b33db6a6524db05067ec1b9--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 1 Nov 2014 02:08:34 +0100
Raw View
On Tue, Oct 28, 2014 at 6:12 PM, Richard Smith <richard@metafoo.co.uk> wrot=
e:
>> Why would it be ridiculous?
>
>
> Because the conversion is const-correct already. The const_cast would be
> entirely spurious, and would be confusing and harmful to readers of the
> code.
Only if you started with a non-const pointer to s.
I was playing with the example in GCC and this didn't work.
Shouldn't it work?
$ cat -n b.cpp
1 int main()
2 {
3 struct S {
4 const int *p;
5 } s;
6 const S& a =3D s;
7 const int** p =3D &s.p;
8 auto q =3D &s.p;
9 // S *q =3D reinterpret_cast<S*>(p);
10 }
$ g++ b.cpp
b.cpp: In function =E2=80=98int main()=E2=80=99:
b.cpp:8:7: error: =E2=80=98q=E2=80=99 does not name a type
auto q =3D &s.p;
^
$ g++ -v
Using built-in specs.
COLLECT_GCC=3Dg++
COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/i586-linux-gnu/4.9/lto-wrapper
Target: i586-linux-gnu
Configured with: ../src/configure -v --with-pkgversion=3D'Debian
4.9.1-19' --with-bugurl=3Dfile:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=3Dc,c++,java,go,d,fortran,objc,obj-c++ --prefix=3D/usr
--program-suffix=3D-4.9 --enable-shared --enable-linker-build-id
--libexecdir=3D/usr/lib --without-included-gettext
--enable-threads=3Dposix --with-gxx-include-dir=3D/usr/include/c++/4.9
--libdir=3D/usr/lib --enable-nls --with-sysroot=3D/ --enable-clocale=3Dgnu
--enable-libstdcxx-debug --enable-libstdcxx-time=3Dyes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=3Dgtk
--enable-gtk-cairo
--with-java-home=3D/usr/lib/jvm/java-1.5.0-gcj-4.9-i386/jre
--enable-java-home
--with-jvm-root-dir=3D/usr/lib/jvm/java-1.5.0-gcj-4.9-i386
--with-jvm-jar-dir=3D/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-i386
--with-arch-directory=3Di386
--with-ecj-jar=3D/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-targets=3Dall --enable-multiarch --with-arch-32=3Di586
--with-multilib-list=3Dm32,m64,mx32 --enable-multilib
--with-tune=3Dgeneric --enable-checking=3Drelease --build=3Di586-linux-gnu
--host=3Di586-linux-gnu --target=3Di586-linux-gnu
Thread model: posix
gcc version 4.9.1 (Debian 4.9.1-19)
--=20
Olaf
--=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: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 31 Oct 2014 18:18:30 -0700
Raw View
--047d7b3a911c35a1730506c1e42e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Fri, Oct 31, 2014 at 6:08 PM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:
> On Tue, Oct 28, 2014 at 6:12 PM, Richard Smith <richard@metafoo.co.uk>
> wrote:
> >> Why would it be ridiculous?
> >
> >
> > Because the conversion is const-correct already. The const_cast would b=
e
> > entirely spurious, and would be confusing and harmful to readers of the
> > code.
>
> Only if you started with a non-const pointer to s.
>
That's not true. If the 's' object were non-const, I'd have started with a
'const int *const *', not a 'const int **'. Because I started with a 'const
int**', I know the 's' is not constant. The constness of the pointee of s's
member 'p' is entirely unrelated to the constness of 's'.
> I was playing with the example in GCC and this didn't work.
> Shouldn't it work?
>
> $ cat -n b.cpp
> 1 int main()
> 2 {
> 3 struct S {
> 4 const int *p;
> 5 } s;
> 6 const S& a =3D s;
> 7 const int** p =3D &s.p;
>
Note, 'const int** p =3D &a.p;' would be ill-formed because it's not
const-correct.
> 8 auto q =3D &s.p;
> 9 // S *q =3D reinterpret_cast<S*>(p);
> 10 }
>
> $ g++ b.cpp
> b.cpp: In function =E2=80=98int main()=E2=80=99:
> b.cpp:8:7: error: =E2=80=98q=E2=80=99 does not name a type
> auto q =3D &s.p;
> ^
>
You forgot to turn on C++11 mode.
--=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/.
--047d7b3a911c35a1730506c1e42e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Oct 31, 2014 at 6:08 PM, Olaf van der Spek <span dir=3D"ltr"><<a hre=
f=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a=
>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On T=
ue, Oct 28, 2014 at 6:12 PM, Richard Smith <<a href=3D"mailto:richard@me=
tafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
>> Why would it be ridiculous?<br>
><br>
><br>
> Because the conversion is const-correct already. The const_cast would =
be<br>
> entirely spurious, and would be confusing and harmful to readers of th=
e<br>
> code.<br>
<br>
</span>Only if you started with a non-const pointer to s.<br></blockquote><=
div><br></div><div>That's not true. If the 's' object were non-=
const, I'd have started with a 'const int *const *', not a '=
;const int **'. Because I started with a 'const int**', I know =
the 's' is not constant. The constness of the pointee of s's me=
mber 'p' is entirely unrelated to the constness of 's'.</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">
I was playing with the example in GCC and this didn't work.<br>
Shouldn't it work?<br>
<br>
$ cat -n b.cpp<br>
=C2=A0 =C2=A0 =C2=A01=C2=A0 int main()<br>
=C2=A0 =C2=A0 =C2=A02=C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A03=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct S {<br>
=C2=A0 =C2=A0 =C2=A04=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 const int *p;<br>
=C2=A0 =C2=A0 =C2=A05=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } s;<br>
=C2=A0 =C2=A0 =C2=A06=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const S& a =3D =
s;<br>
=C2=A0 =C2=A0 =C2=A07=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 const int** p =3D &=
amp;s.p;<br></blockquote><div><br></div><div>Note, 'const int** p =3D &=
amp;a.p;' would be ill-formed because it's not const-correct.</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">
=C2=A0 =C2=A0 =C2=A08=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 auto q =3D &s.p=
;<br>
=C2=A0 =C2=A0 =C2=A09=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // S *q =3D reinter=
pret_cast<S*>(p);<br>
=C2=A0 =C2=A0 10=C2=A0 }<br>
<br>
$ g++ b.cpp<br>
b.cpp: In function =E2=80=98int main()=E2=80=99:<br>
b.cpp:8:7: error: =E2=80=98q=E2=80=99 does not name a type<br>
=C2=A0 auto q =3D &s.p;<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0^<br></blockquote><div><br></div><div>You forgot=
to turn on C++11 mode.=C2=A0</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--047d7b3a911c35a1730506c1e42e--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Sat, 1 Nov 2014 13:48:18 +0100
Raw View
On Sat, Nov 1, 2014 at 2:18 AM, Richard Smith <richard@metafoo.co.uk> wrote:
> On Fri, Oct 31, 2014 at 6:08 PM, Olaf van der Spek <olafvdspek@gmail.com>
> wrote:
>>
>> On Tue, Oct 28, 2014 at 6:12 PM, Richard Smith <richard@metafoo.co.uk>
>> wrote:
>> >> Why would it be ridiculous?
>> >
>> >
>> > Because the conversion is const-correct already. The const_cast would be
>> > entirely spurious, and would be confusing and harmful to readers of the
>> > code.
>>
>> Only if you started with a non-const pointer to s.
>
>
> That's not true. If the 's' object were non-const, I'd have started with a
> 'const int *const *', not a 'const int **'. Because I started with a 'const
> int**', I know the 's' is not constant. The constness of the pointee of s's
> member 'p' is entirely unrelated to the constness of 's'.
Right.
So if p were const& or const int const* the trick to get a non-const s
wouldn't work right, even if s is non-const?
My original question was: "There's no technical reason to allow this
removal of const by
reinterpret_cast<> is there?"
In this case it's not (really) removing const is it, as the code is
const-correct.
> You forgot to turn on C++11 mode.
I'm such a noob. :p
--
Olaf
--
---
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/.
.