Topic: Add a function "as_const" to turn a non-const
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sat, 16 Aug 2014 04:05:41 -0700 (PDT)
Raw View
------=_Part_1145_1323165378.1408187141185
Content-Type: text/plain; charset=UTF-8
Sometimes it's desirable to use const methods on a non-const object.
This can be done with const_cast, but const_cast can equally well be used
to do potentially unsafe things and is often flagged up in code reviews or
banned outright by coding standards/pre-commit scripts.
I propose the addition of a simple function:
template <typename T>
std::as_const(T&& t)
{
return const_cast<const T&&>(t);
}
which can be used to perform the safe const-cast operation.
--
---
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_1145_1323165378.1408187141185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Sometimes it's desirable to use const methods on a non-con=
st object.<div>This can be done with const_cast, but const_cast can equally=
well be used to do potentially unsafe things and is often flagged up in co=
de reviews or banned outright by coding standards/pre-commit scripts.</div>=
<div><br></div><div>I propose the addition of a simple function:</div><div>=
<br></div><div>template <typename T></div><div>std::as_const(T&&a=
mp; t) </div><div>{ </div><div> return const_cast<const =
T&&>(t); </div><div>}</div><div><br></div><div>which can be=
used to perform the safe const-cast operation.</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_1145_1323165378.1408187141185--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 16 Aug 2014 21:23:48 +0800
Raw View
--Apple-Mail=_9CF22524-D53B-4B5D-B841-0D0853FE847B
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-16, at 7:05 PM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
> Sometimes it's desirable to use const methods on a non-const object.
> This can be done with const_cast, but const_cast can equally well be used to do potentially unsafe things and is often flagged up in code reviews or banned outright by coding standards/pre-commit scripts.
It can also be done with static_cast.
The proposal is still nice.
--
---
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=_9CF22524-D53B-4B5D-B841-0D0853FE847B
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 2014&=
ndash;08–16, at 7:05 PM, Jonathan Coe <<a href=3D"mailto:jonathanb=
coe@gmail.com">jonathanbcoe@gmail.com</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">Sometimes=
it's desirable to use const methods on a non-const object.<div>This can be=
done with const_cast, but const_cast can equally well be used to do potent=
ially unsafe things and is often flagged up in code reviews or banned outri=
ght by coding standards/pre-commit scripts.</div></div></blockquote><div><b=
r></div>It can also be done with <font face=3D"Courier">static_cast</font>.=
</div><div><br></div><div>The proposal is still nice.<br></div><div><br></d=
iv><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=_9CF22524-D53B-4B5D-B841-0D0853FE847B--
.
Author: "'Geoffrey Romer' via ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Date: Sat, 16 Aug 2014 12:01:26 -0700
Raw View
--001a113b3e04be48840500c3c301
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
implicit_cast is nice for situations like this, if you have it=E2=80=94 sta=
tic_cast
can still do unwelcome things if you're not careful. Speaking of which, we
ought to standardize implicit_cast.
On Aug 16, 2014 6:23 AM, "David Krauss" <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9316, at 7:05 PM, Jonathan Coe <jonathanbcoe@gma=
il.com> wrote:
>
> Sometimes it's desirable to use const methods on a non-const object.
> This can be done with const_cast, but const_cast can equally well be used
> to do potentially unsafe things and is often flagged up in code reviews o=
r
> banned outright by coding standards/pre-commit scripts.
>
>
> It can also be done with static_cast.
>
> The proposal is still nice.
>
>
> --
>
> ---
> 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/.
--001a113b3e04be48840500c3c301
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">implicit_cast is nice for situations like this, if you have =
it=E2=80=94 static_cast can still do unwelcome things if you're not car=
eful. Speaking of which, we ought to standardize implicit_cast.</p>
<div class=3D"gmail_quote">On Aug 16, 2014 6:23 AM, "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">
<div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9308=E2=80=
=9316, at 7:05 PM, Jonathan Coe <<a href=3D"mailto:jonathanbcoe@gmail.co=
m" target=3D"_blank">jonathanbcoe@gmail.com</a>> wrote:</div><br><blockq=
uote type=3D"cite"><div dir=3D"ltr">
Sometimes it's desirable to use const methods on a non-const object.<di=
v>This can be done with const_cast, but const_cast can equally well be used=
to do potentially unsafe things and is often flagged up in code reviews or=
banned outright by coding standards/pre-commit scripts.</div>
</div></blockquote><div><br></div>It can also be done with <font face=3D"Co=
urier">static_cast</font>.</div><div><br></div><div>The proposal is still n=
ice.<br></div><div><br></div><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" 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>
</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 />
--001a113b3e04be48840500c3c301--
.
Author: Eelis <eelis@eelis.net>
Date: Sat, 16 Aug 2014 21:43:25 +0200
Raw View
On 2014-08-16 21:01, 'Geoffrey Romer' via ISO C++ Standard - Future
Proposals wrote:
> we ought to standardize implicit_cast.
+1
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Sat, 16 Aug 2014 16:03:42 -0400
Raw View
--001a11c247e47aa97e0500c4a22e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:
> implicit_cast is nice for situations like this, if you have it=E2=80=94
> static_cast can still do unwelcome things if you're not careful. Speaking
> of which, we ought to standardize implicit_cast.
>
Implicit conversion cab still do unwelcome things like
narrowing, unsigned to signed, etc.
And it's verbose, especially when T is verbose or
it's tricky to const qualify T. to/as_const, to/as_unsigned
are convenient type deduced interfaces, and not possible
to go wrong.
--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--=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/.
--001a11c247e47aa97e0500c4a22e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sat, Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' =
via ISO C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"ma=
ilto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</=
a>></span> wrote:<br>
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><p dir=3D"ltr">implicit_cast is nice for situations like this, if=
you have it=E2=80=94 static_cast can still do unwelcome things if you'=
re not careful. Speaking of which, we ought to standardize implicit_cast.</=
p>
</blockquote></div>Implicit conversion cab still do unwelcome things like<b=
r>narrowing, unsigned to signed, etc.<br><br></div><div class=3D"gmail_extr=
a">And it's verbose, especially when T is verbose or<br></div><div clas=
s=3D"gmail_extra">
it's tricky to const qualify T.=C2=A0 to/as_const, to/as_unsigned<br></=
div><div class=3D"gmail_extra">are convenient type deduced interfaces, and =
not possible<br>to go wrong.<br></div><div class=3D"gmail_extra"><br>-- <br=
>Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>____________________=
_______________________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bs=
d" target=3D"_blank">http://bit.ly/blog4bsd</a>
</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 />
--001a11c247e47aa97e0500c4a22e--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 16 Aug 2014 22:46:44 +0200
Raw View
--089e01183b7056681e0500c53c51
Content-Type: text/plain; charset=UTF-8
On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <jonathanbcoe@gmail.com>
wrote:
> Sometimes it's desirable to use const methods on a non-const object.
>
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/.
--089e01183b7056681e0500c53c51
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <span dir="ltr"><<a href="mailto:jonathanbcoe@gmail.com" target="_blank">jonathanbcoe@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Sometimes it's desirable to use const methods on a non-const object.<div></div></div></blockquote></div>
<br></div><div class="gmail_extra">For example?</div><div class="gmail_extra"><br></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--089e01183b7056681e0500c53c51--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Sun, 17 Aug 2014 09:56:08 +0200
Raw View
Il giorno 16/ago/2014, alle ore 22:46, Andrew Tomazos <andrewtomazos@gmail.com> ha scritto:
> On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
> Sometimes it's desirable to use const methods on a non-const object.
>
> For example?
>
>
std::map::operator[]
Bye,
Nicola
--
---
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 Tomazos <andrewtomazos@gmail.com>
Date: Sun, 17 Aug 2014 10:49:41 +0200
Raw View
--047d7bdca524d0e5d00500cf5597
Content-Type: text/plain; charset=UTF-8
On Sun, Aug 17, 2014 at 9:56 AM, Nicola Gigante <nicola.gigante@gmail.com>
wrote:
>
> Il giorno 16/ago/2014, alle ore 22:46, Andrew Tomazos <
> andrewtomazos@gmail.com> ha scritto:
>
> > On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <jonathanbcoe@gmail.com>
> wrote:
> > Sometimes it's desirable to use const methods on a non-const object.
> >
> > For example?
> >
>
> std::map::operator[]
>
> std::map::operator[] is not a "const method".
--
---
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/.
--047d7bdca524d0e5d00500cf5597
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Aug 17, 2014 at 9:56 AM, Nicola Gigante <span dir="ltr"><<a href="mailto:nicola.gigante@gmail.com" target="_blank">nicola.gigante@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Il giorno 16/ago/2014, alle ore 22:46, Andrew Tomazos <<a href="mailto:andrewtomazos@gmail.com">andrewtomazos@gmail.com</a>> ha scritto:<br>
<div class=""><br>
> On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <<a href="mailto:jonathanbcoe@gmail.com">jonathanbcoe@gmail.com</a>> wrote:<br>
> Sometimes it's desirable to use const methods on a non-const object.<br>
><br>
> For example?<br>
><br><br>
</div>std::map::operator[]<br><br></blockquote><div>std::map::operator[] is not a "const method".</div><div><br></div></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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--047d7bdca524d0e5d00500cf5597--
.
Author: Nicola Gigante <nicola.gigante@gmail.com>
Date: Sun, 17 Aug 2014 11:53:41 +0200
Raw View
Il giorno 17/ago/2014, alle ore 10:49, Andrew Tomazos <andrewtomazos@gmail.com> ha scritto:
>
> std::map::operator[] is not a "const method".
>
Wops, sorry..
--
---
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, 17 Aug 2014 03:29:46 -0700 (PDT)
Raw View
------=_Part_1042_415209505.1408271386121
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
+1 to as_signed/as_unsigned, very convenient to deal with "signed/unsigned=
=20
mismatch" warnings and to use with auto <http://herbsutter.com/?s=3Das_sign=
ed>
On Sunday, August 17, 2014 12:03:46 AM UTC+4, Zhihao Yuan wrote:
>
> On Sat, Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' via ISO C++ Standard -=
=20
> Future Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>
>> implicit_cast is nice for situations like this, if you have it=E2=80=94=
=20
>> static_cast can still do unwelcome things if you're not careful. Speakin=
g=20
>> of which, we ought to standardize implicit_cast.
>>
> Implicit conversion cab still do unwelcome things like
> narrowing, unsigned to signed, etc.
>
> And it's verbose, especially when T is verbose or
> it's tricky to const qualify T. to/as_const, to/as_unsigned
> are convenient type deduced interfaces, and not possible
> to go wrong.
>
> --=20
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://bit.ly/blog4bsd=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 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_1042_415209505.1408271386121
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">+1 to as_signed/as_unsigned, very convenient to deal with =
"signed/unsigned mismatch" warnings and to use with <a href=3D"http://herbs=
utter.com/?s=3Das_signed">auto</a><br><br>On Sunday, August 17, 2014 12:03:=
46 AM UTC+4, Zhihao Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">On Sat, Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' via ISO=
C++ Standard - Future Proposals <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"EN8mzXRGWD0J" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">std-pr...@isocpp.org</a>></span> wrote:<br>
<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"lt=
r">implicit_cast is nice for situations like this, if you have it=E2=80=94 =
static_cast can still do unwelcome things if you're not careful. Speaking o=
f which, we ought to standardize implicit_cast.</p>
</blockquote></div>Implicit conversion cab still do unwelcome things like<b=
r>narrowing, unsigned to signed, etc.<br><br></div><div>And it's verbose, e=
specially when T is verbose or<br></div><div>
it's tricky to const qualify T. to/as_const, to/as_unsigned<br></div>=
<div>are convenient type deduced interfaces, and not possible<br>to go wron=
g.<br></div><div><br>-- <br>Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>____________________=
_______________________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bs=
d" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA=
3DF1H_gEgIkwnCr7FAkiCyQ';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg=
\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return true;">http://bit.ly/blog4bsd=
</a>
</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_1042_415209505.1408271386121--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Sun, 17 Aug 2014 11:57:14 +0100
Raw View
--Apple-Mail-4C0145B7-B7EA-4CE2-8378-DE93FAE3944C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
+1=20
to as _signed as_unsigned
> On 17 Aug 2014, at 11:29, vadim.petrochenkov@gmail.com wrote:
>=20
> +1 to as_signed/as_unsigned, very convenient to deal with "signed/unsigne=
d mismatch" warnings and to use with auto
>=20
>> On Sunday, August 17, 2014 12:03:46 AM UTC+4, Zhihao Yuan wrote:
>>> On Sat, Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' via ISO C++ Standard =
- Future Proposals <std-pr...@isocpp.org> wrote:
>>> implicit_cast is nice for situations like this, if you have it=E2=80=94=
static_cast can still do unwelcome things if you're not careful. Speaking =
of which, we ought to standardize implicit_cast.
>>>=20
>> Implicit conversion cab still do unwelcome things like
>> narrowing, unsigned to signed, etc.
>>=20
>> And it's verbose, especially when T is verbose or
>> it's tricky to const qualify T. to/as_const, to/as_unsigned
>> are convenient type deduced interfaces, and not possible
>> to go wrong.
>>=20
>> --=20
>> Zhihao Yuan, ID lichray
>> The best way to predict the future is to invent it.
>> ___________________________________________________
>> 4BSD -- http://bit.ly/blog4bsd
>=20
> --=20
>=20
> ---=20
> You received this message because you are subscribed to the Google Groups=
"ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-propo=
sals/.
--=20
---=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-4C0145B7-B7EA-4CE2-8378-DE93FAE3944C
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>+1 </div><div>to as _signed a=
s_unsigned</div><div><br></div><div><br>On 17 Aug 2014, at 11:29, <a href=
=3D"mailto:vadim.petrochenkov@gmail.com">vadim.petrochenkov@gmail.com</a> w=
rote:<br><br></div><blockquote type=3D"cite"><div><div dir=3D"ltr">+1 to as=
_signed/as_unsigned, very convenient to deal with "signed/unsigned mismatch=
" warnings and to use with <a href=3D"http://herbsutter.com/?s=3Das_signed"=
>auto</a><br><br>On Sunday, August 17, 2014 12:03:46 AM UTC+4, Zhihao Yuan =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On Sat,=
Aug 16, 2014 at 3:01 PM, 'Geoffrey Romer' via ISO C++ Standard - Future Pr=
oposals <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"EN8mzXRGWD0J" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">std-pr..=
..@isocpp.org</a>></span> wrote:<br>
<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"lt=
r">implicit_cast is nice for situations like this, if you have it=E2=80=94 =
static_cast can still do unwelcome things if you're not careful. Speaking o=
f which, we ought to standardize implicit_cast.</p>
</blockquote></div>Implicit conversion cab still do unwelcome things like<b=
r>narrowing, unsigned to signed, etc.<br><br></div><div>And it's verbose, e=
specially when T is verbose or<br></div><div>
it's tricky to const qualify T. to/as_const, to/as_unsigned<br></div>=
<div>are convenient type deduced interfaces, and not possible<br>to go wron=
g.<br></div><div><br>-- <br>Zhihao Yuan, ID lichray<br>
The best way to predict the future is to invent it.<br>____________________=
_______________________________<br>4BSD -- <a href=3D"http://bit.ly/blog4bs=
d" target=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg\75AFQjCNENWZA=
3DF1H_gEgIkwnCr7FAkiCyQ';return true;" onclick=3D"this.href=3D'http://www.g=
oogle.com/url?q\75http%3A%2F%2Fbit.ly%2Fblog4bsd\46sa\75D\46sntz\0751\46usg=
\75AFQjCNENWZA3DF1H_gEgIkwnCr7FAkiCyQ';return true;">http://bit.ly/blog4bsd=
</a>
</div></div>
</blockquote></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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</div></blockquote></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-4C0145B7-B7EA-4CE2-8378-DE93FAE3944C--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 18 Aug 2014 08:08:21 +0800
Raw View
--Apple-Mail=_740A728C-40AD-4776-8495-A3CBBA6B4A2D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
as_signed sounds like a recipe for overflow. If you want to simply defeat t=
he warnings, disable them with a compiler flag, not by explicitly translati=
ng them to UB. boost::numeric_cast could encourage better practices.
One use case for as_const would be a user-defined container, as an alternat=
ive to implementing the boilerplate cbegin() and cend(). I have to admit, t=
hough, that at the cost of one extra line you can always just declare a con=
st reference. (If the variable is a temporary, it could be trickier, but wh=
en does a temporary need to be const?)
On 2014-08-17, at 6:57 PM, Jonathan Coe <jonathanbcoe@gmail.com> wrote:
> +1=20
> to as _signed as_unsigned
--=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=_740A728C-40AD-4776-8495-A3CBBA6B4A2D
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;"><font face=3D"Courier"=
>as_signed</font> sounds like a recipe for overflow. If you want to simply =
defeat the warnings, disable them with a compiler flag, not by explicitly t=
ranslating them to UB. <font face=3D"Courier">boost::numeric_cast</fon=
t> could encourage better practices.<div><br></div><div>One use case for <f=
ont face=3D"Courier">as_const</font> would be a user-defined container=
, as an alternative to implementing the boilerplate <font face=3D"Cour=
ier">cbegin()</font> and <font face=3D"Courier">cend()</font>. I have to ad=
mit, though, that at the cost of one extra line you can always just declare=
a const reference. (If the variable is a temporary, it could be trickier, =
but when does a temporary need to be const?)</div><div><br><div><div>On 201=
4–08–17, at 6:57 PM, Jonathan Coe <<a href=3D"mailto:jonatha=
nbcoe@gmail.com">jonathanbcoe@gmail.com</a>> wrote:</div><br class=3D"Ap=
ple-interchange-newline"><blockquote type=3D"cite"><meta http-equiv=3D"cont=
ent-type" content=3D"text/html; charset=3Dutf-8"><div dir=3D"auto"><div>+1&=
nbsp;</div><div>to as _signed as_unsigned</div></div></blockquote></div><br=
></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_740A728C-40AD-4776-8495-A3CBBA6B4A2D--
.
Author: vadim.petrochenkov@gmail.com
Date: Mon, 18 Aug 2014 01:11:26 -0700 (PDT)
Raw View
------=_Part_1470_1773540401.1408349486251
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>as_signed sounds like a recipe for overflow
No more than any other signed arithmetic.
A typical example of use:
std::string getWordForm(const Sentence& sent, Sentence::size_type abs_pos,=
=20
Sentence::difference_type shift)
{
std::string form;
auto pos =3D as_signed(abs_pos) + shift;
if (pos >=3D 0 && as_unsigned(pos) < sent.size()) form =3D sent[
as_unsigned(pos)].form();
return form;
}
To think about overflow here would be just excessive.
(And look at the dangerous operator+, I'd better use boost::checked_add!)
>to simply defeat the warnings, disable them with a compiler flag
I'd prefer the conversions to be explicit, and doing static_casts is=20
unwieldy.
On Monday, August 18, 2014 4:08:20 AM UTC+4, David Krauss wrote:
>
> as_signed sounds like a recipe for overflow. If you want to simply defeat=
=20
> the warnings, disable them with a compiler flag, not by explicitly=20
> translating them to UB. boost::numeric_cast could encourage better=20
> practices.
>
> One use case for as_const would be a user-defined container, as an=20
> alternative to implementing the boilerplate cbegin() and cend(). I have=
=20
> to admit, though, that at the cost of one extra line you can always just=
=20
> declare a const reference. (If the variable is a temporary, it could be=
=20
> trickier, but when does a temporary need to be const?)
>
> On 2014=E2=80=9308=E2=80=9317, at 6:57 PM, Jonathan Coe <jonath...@gmail.=
com <javascript:>>=20
> wrote:
>
> +1=20
> to as _signed as_unsigned
>
>
>
--=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_1470_1773540401.1408349486251
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>as_signed sounds like a recipe for overflow</div>=
<div><br></div><div>No more than any other signed arithmetic.</div><div>A t=
ypical example of use:</div><div><br></div><div><div style=3D"background-co=
lor: #FAFAFA; border-color: #BBB; border-style: solid; border-width: 1px; w=
ord-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify">stri=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> getWord=
Form</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Sentence</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> sent</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Sentence</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">size_type abs_pos</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Se=
ntence</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">difference_t=
ype shift</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">string</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> form</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> pos </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> as_signed</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">abs_pos</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> shift</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">pos </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">>=3D</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&&</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> as_unsigned</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">pos</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> sent</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">())</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> form </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> sent</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">as_unsigned</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">pos</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">)].</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">form</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> form</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span></div></code></div><br>To think a=
bout overflow here would be just excessive.</div><div>(And look at the dang=
erous operator+, I'd better use boost::checked_add!)<br><br></div><div>>=
to simply defeat the warnings, disable them with a compiler flag</div><div>=
I'd prefer the conversions to be explicit, and doing static_casts is unwiel=
dy.</div><br>On Monday, August 18, 2014 4:08:20 AM UTC+4, David Krauss wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:brea=
k-word"><font face=3D"Courier">as_signed</font> sounds like a recipe for ov=
erflow. If you want to simply defeat the warnings, disable them with a comp=
iler flag, not by explicitly translating them to UB. <font face=3D"Cou=
rier">boost::numeric_cast</font> could encourage better practices.<div><br>=
</div><div>One use case for <font face=3D"Courier">as_const</font> wou=
ld be a user-defined container, as an alternative to implementing the boile=
rplate <font face=3D"Courier">cbegin()</font> and <font face=3D"Courie=
r">cend()</font>. I have to admit, though, that at the cost of one extra li=
ne you can always just declare a const reference. (If the variable is a tem=
porary, it could be trickier, but when does a temporary need to be const?)<=
/div><div><br><div><div>On 2014=E2=80=9308=E2=80=9317, at 6:57 PM, Jonathan=
Coe <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"QxRIZmiVjvUJ" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">jonath...@gmail.com</a>> w=
rote:</div><br><blockquote type=3D"cite"><div dir=3D"auto"><div>+1 </d=
iv><div>to as _signed as_unsigned</div></div></blockquote></div><br></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_1470_1773540401.1408349486251--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 18 Aug 2014 19:14:54 -0700 (PDT)
Raw View
------=_Part_3816_1183492174.1408414494167
Content-Type: text/plain; charset=UTF-8
On Monday, August 18, 2014 1:11:26 AM UTC-7, vadim.pet...@gmail.com wrote:
>
> >as_signed sounds like a recipe for overflow
>
> No more than any other signed arithmetic.
> A typical example of use:
>
>
These are very problematic. Let's say you wrote code like this:
// Make sure that this multiplication is unsigned so that when it overflows,
// it is well-defined as wrapping around.
template <typename X>
X wrap_square(X x)
{
return static_cast<X>(as_unsigned(x) * as_unsigned(x));
}
....except that this is wrong: it has undefined behavior on 32-bit machines
when X is std::uint16_t. Despite the attempt at doing unsigned arithmetic,
it still is doing signed arithmetic. Worse yet, this is platform-specific.
(This is why I downright hate signed integer overflow being undefined.)
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_3816_1183492174.1408414494167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 18, 2014 1:11:26 AM UTC-7, vadim.pet...@=
gmail.com 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"lt=
r"><div>>as_signed sounds like a recipe for overflow</div><div><br></div=
><div>No more than any other signed arithmetic.</div><div>A typical example=
of use:</div><br></div></blockquote><div><br>These are very problematic.&n=
bsp; Let's say you wrote code like this:<br><br><div class=3D"prettyprint" =
style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, =
187); border-style: solid; border-width: 1px; word-wrap: break-word;"><code=
class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: =
#800;" class=3D"styled-by-prettify">// Make sure that this multiplication i=
s unsigned so that when it overflows,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D=
"styled-by-prettify">// it is well-defined as wrapping around.</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><</span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> X</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>X wrap_square</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">X x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">static_cast</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">X</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">>(</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">as_unsigned</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>*</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> as_unsi=
gned</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">x</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br></span></div></code></div><br>...except th=
at this is wrong: it has undefined behavior on 32-bit machines when X is st=
d::uint16_t. Despite the attempt at doing unsigned arithmetic, it sti=
ll is doing signed arithmetic. Worse yet, this is platform-specific.<=
br><br>(This is why I downright hate signed integer overflow being undefine=
d.)<br><br>Melissa<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_3816_1183492174.1408414494167--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Mon, 18 Aug 2014 19:58:53 -0700 (PDT)
Raw View
------=_Part_713_1019040729.1408417133617
Content-Type: text/plain; charset=UTF-8
\On Saturday, August 16, 2014 7:05:41 AM UTC-4, Jonathan Coe wrote:
>
> Sometimes it's desirable to use const methods on a non-const object.
> This can be done with const_cast, but const_cast can equally well be used
> to do potentially unsafe things and is often flagged up in code reviews or
> banned outright by coding standards/pre-commit scripts.
>
What am I missing here? You can already use const methods on non-const
objects without a cast. Are you trying to select a const overload in favor
of a non-const overload?
--
---
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_713_1019040729.1408417133617
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">\On Saturday, August 16, 2014 7:05:41 AM UTC-4, Jonathan C=
oe 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">Some=
times it's desirable to use const methods on a non-const object.<div>This c=
an be done with const_cast, but const_cast can equally well be used to do p=
otentially unsafe things and is often flagged up in code reviews or banned =
outright by coding standards/pre-commit scripts.</div></div></blockquote><d=
iv><br></div><div>What am I missing here? You can already use const m=
ethods on non-const objects without a cast. Are you trying to select =
a const overload in favor of a non-const overload?</div><div><br></div></di=
v>
<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_713_1019040729.1408417133617--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Mon, 18 Aug 2014 23:08:33 -0400
Raw View
--------------010301040007000702010305
Content-Type: text/plain; charset=UTF-8; format=flowed
On 08/18/2014 10:14 PM, Myriachan wrote:
> On Monday, August 18, 2014 1:11:26 AM UTC-7, vadim.pet...@gmail.com
> wrote:
>
> >as_signed sounds like a recipe for overflow
>
> No more than any other signed arithmetic.
> A typical example of use:
>
>
> These are very problematic. Let's say you wrote code like this:
>
> |
> // Make sure that this multiplication is unsigned so that when it
> overflows,
> // it is well-defined as wrapping around.
> template<typenameX>
> X wrap_square(X x)
> {
> returnstatic_cast<X>(as_unsigned(x)*as_unsigned(x));
> }
> |
>
> ...except that this is wrong: it has undefined behavior on 32-bit
> machines when X is std::uint16_t. Despite the attempt at doing
> unsigned arithmetic, it still is doing signed arithmetic. Worse yet,
> this is platform-specific.
Would it be terrible if as_unsigned() implicitly applied promotions?
Alternatively, as_unsigned_promoted(x).
Tom.
--
---
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/.
--------------010301040007000702010305
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
On 08/18/2014 10:14 PM, Myriachan wrote:<br>
<blockquote
cite=3D"mid:84102547-d4cc-426f-a15a-52835001ff4e@isocpp.org"
type=3D"cite">
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf=
-8">
<div dir=3D"ltr">On Monday, August 18, 2014 1:11:26 AM UTC-7,
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:vadim.pet...@g=
mail.com">vadim.pet...@gmail.com</a> 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">
<div>>as_signed sounds like a recipe for overflow</div>
<div><br>
</div>
<div>No more than any other signed arithmetic.</div>
<div>A typical example of use:</div>
<br>
</div>
</blockquote>
<div><br>
These are very problematic.=C2=A0 Let's say you wrote code like
this:<br>
<br>
<div class=3D"prettyprint" style=3D"background-color: rgb(250,
250, 250); border-color: rgb(187, 187, 187); border-style:
solid; border-width: 1px; word-wrap: break-word;"><code
class=3D"prettyprint">
<div class=3D"subprettyprint"><span style=3D"color: #800;"
class=3D"styled-by-prettify">// Make sure that this
multiplication is unsigned so that when it overflows,</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #800;"
class=3D"styled-by-prettify">// it is well-defined as
wrapping around.</span><span style=3D"color: #000;"
class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #008;"
class=3D"styled-by-prettify">template</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> X</s=
pan><span
style=3D"color: #660;" class=3D"styled-by-prettify">><=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
X wrap_square</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify">X x</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">{</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"><br>
=C2=A0 =C2=A0 </span><span style=3D"color: #008;"
class=3D"styled-by-prettify">return</span><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #008;" class=3D"styled-by-prettify">stati=
c_cast</span><span
style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span
style=3D"color: #000;" class=3D"styled-by-prettify">X</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span
style=3D"color: #000;" class=3D"styled-by-prettify">as_un=
signed</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">)</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span
style=3D"color: #660;" class=3D"styled-by-prettify">*</sp=
an><span
style=3D"color: #000;" class=3D"styled-by-prettify">
as_unsigned</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">(</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify">x</span><span
style=3D"color: #660;" class=3D"styled-by-prettify">));</=
span><span
style=3D"color: #000;" class=3D"styled-by-prettify"><br>
</span><span style=3D"color: #660;"
class=3D"styled-by-prettify">}</span><span style=3D"color=
:
#000;" class=3D"styled-by-prettify"><br>
</span></div>
</code></div>
<br>
...except that this is wrong: it has undefined behavior on
32-bit machines when X is std::uint16_t.=C2=A0 Despite the attemp=
t
at doing unsigned arithmetic, it still is doing signed
arithmetic.=C2=A0 Worse yet, this is platform-specific.<br>
</div>
</div>
</blockquote>
<br>
Would it be terrible if as_unsigned() implicitly applied
promotions?=C2=A0 Alternatively, as_unsigned_promoted(x).=C2=A0 <br>
<br>
Tom.<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 />
--------------010301040007000702010305--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 19 Aug 2014 05:12:55 +0200
Raw View
--001a11c30ad0287f6c0500f2dd13
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 19, 2014 at 4:58 AM, Greg Marr <gregmmarr@gmail.com> wrote:
> \On Saturday, August 16, 2014 7:05:41 AM UTC-4, Jonathan Coe wrote:
>>
>> Sometimes it's desirable to use const methods on a non-const object.
>> This can be done with const_cast, but const_cast can equally well be used
>> to do potentially unsafe things and is often flagged up in code reviews or
>> banned outright by coding standards/pre-commit scripts.
>>
>
> What am I missing here? You can already use const methods on non-const
> objects without a cast. Are you trying to select a const overload in favor
> of a non-const overload?
>
I share your skepticism, and am still waiting for a motivating code example
of where as_const is needed.
--
---
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/.
--001a11c30ad0287f6c0500f2dd13
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, Aug 19, 2014 at 4:58 AM, Greg Marr <span dir=3D"ltr"><<a href=3D"mai=
lto:gregmmarr@gmail.com" target=3D"_blank">gregmmarr@gmail.com</a>></spa=
n> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">\On Saturda=
y, August 16, 2014 7:05:41 AM UTC-4, Jonathan Coe wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr">Sometimes it's desirable to use const methods on a non=
-const object.<div>This can be done with const_cast, but const_cast can equ=
ally well be used to do potentially unsafe things and is often flagged up i=
n code reviews or banned outright by coding standards/pre-commit scripts.</=
div>
</div></blockquote><div><br></div></div><div>What am I missing here? =C2=A0=
You can already use const methods on non-const objects without a cast. =C2=
=A0Are you trying to select a const overload in favor of a non-const overlo=
ad?</div>
<div></div></div></blockquote></div><br></div><div class=3D"gmail_extra">I =
share your skepticism, and am still waiting for a motivating code example o=
f where as_const is needed.</div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">
<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 />
--001a11c30ad0287f6c0500f2dd13--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Mon, 18 Aug 2014 23:59:35 -0400
Raw View
--001a11c3bee201cf8b0500f38467
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 18, 2014 at 11:12 PM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
>
> I share your skepticism, and am still waiting for a motivating code
> example of where as_const is needed.
>
for (x : as_const(v))
{
// got x from begin const / end const
}
struct Foo
{
T& foo()
{
// maybe more useful with as_non_const?
return const_cast<T&>(as_const(*this).foo());
}
T const& foo() const
{
// ...
}
};
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--001a11c3bee201cf8b0500f38467
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 18, 2014 at 11:12 PM, Andrew Tomazos <span dir=
=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><div class=
=3D"gmail_extra"><br></div></div><div class=3D"gmail_extra">I share your sk=
epticism, and am still waiting for a motivating code example of where as_co=
nst is needed.</div>
</div></blockquote><div><br></div><div>=C2=A0 for (x : as_const(v))<br>=C2=
=A0 {<br></div><div>=C2=A0=C2=A0=C2=A0 // got x from begin const / end cons=
t<br></div><div>=C2=A0 }<br><br></div><div>=C2=A0 struct Foo<br>=C2=A0 {<br=
></div><div>=C2=A0=C2=A0=C2=A0 T& foo()<br>=C2=A0=C2=A0=C2=A0 {<br>
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // maybe more useful with as_non_=
const?<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return const_cast<T&=
amp;>(as_const(*this).foo());<br></div><div>=C2=A0=C2=A0=C2=A0 }<br><br>=
</div><div>=C2=A0=C2=A0=C2=A0 T const& foo() const<br>=C2=A0=C2=A0=C2=
=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...<br>
=C2=A0=C2=A0=C2=A0 }<br></div><div>=C2=A0 };<br><br></div></div>-- <br>Zhih=
ao Yuan, ID lichray<br>The best way to predict the future is to invent it.<=
br>___________________________________________________<br>4BSD -- <a href=
=3D"http://bit.ly/blog4bsd" target=3D"_blank">http://bit.ly/blog4bsd</a>
</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 />
--001a11c3bee201cf8b0500f38467--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 19 Aug 2014 07:06:04 +0200
Raw View
--90e6ba1811d6c2f2980500f471d2
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 19, 2014 at 5:59 AM, Zhihao Yuan <zy@miator.net> wrote:
> On Mon, Aug 18, 2014 at 11:12 PM, Andrew Tomazos <andrewtomazos@gmail.com>
> wrote:
>
>>
>> I share your skepticism, and am still waiting for a motivating code
>> example of where as_const is needed.
>>
>
> for (x : as_const(v))
> {
> // got x from begin const / end const
> }
>
I think this is better:
for (const auto& x : v) { ... }
But STL also has this in the works:
for (const x : v) { ... }
Also, if v is a temporary, will your version be lifetime extended?
struct Foo
> {
> T& foo()
> {
> // maybe more useful with as_non_const?
> return const_cast<T&>(as_const(*this).foo());
> }
>
> T const& foo() const
> {
> // ...
> }
> };
>
>
Presumably, this is if there is a private lvalue being returned:
struct Foo
{
T& getFoo() { return foo; }
const T& getFoo() const { return foo; }
private:
T foo;
};
I still suspect needing as_const is indicative of a design flaw in the
surrounding 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/.
--90e6ba1811d6c2f2980500f471d2
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, Aug 19, 2014 at 5:59 AM, Zhihao Yuan <span dir=3D"ltr"><<a href=3D"m=
ailto:zy@miator.net" target=3D"_blank">zy@miator.net</a>></span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"">On Mon, Aug 18, 2014 at 11:12 PM, Andrew T=
omazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" tar=
get=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br></div><div =
class=3D"gmail_extra">
<div class=3D"gmail_quote"><div class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_extra"><br></div=
></div>
<div class=3D"gmail_extra">I share your skepticism, and am still waiting fo=
r a motivating code example of where as_const is needed.</div>
</div></blockquote><div><br></div></div><div>=C2=A0 for (x : as_const(v))<b=
r>=C2=A0 {<br></div><div>=C2=A0=C2=A0=C2=A0 // got x from begin const / end=
const<br></div><div>=C2=A0 }<br></div></div></div></div></blockquote><div>=
<br></div><div>I think this is better:</div>
<div><br></div><div>=C2=A0 =C2=A0for (const auto& x : v) { ... }</div><=
div><br></div><div>But STL also has this in the works:</div><div><br></div>=
<div>=C2=A0 =C2=A0for (const x : v) { ... }</div><div><br></div><div>Also, =
if v is a temporary, will your version be lifetime extended?<br>
</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra">
<div class=3D"gmail_quote"><div></div><div>=C2=A0 struct Foo<br>=C2=A0 {<br=
></div><div>=C2=A0=C2=A0=C2=A0 T& foo()<br>=C2=A0=C2=A0=C2=A0 {<br>
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // maybe more useful with as_non_=
const?<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return const_cast<T&=
amp;>(as_const(*this).foo());<br></div><div>=C2=A0=C2=A0=C2=A0 }<br><br>=
</div><div>=C2=A0=C2=A0=C2=A0 T const& foo() const<br>=C2=A0=C2=A0=C2=
=A0 {<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...<br>
=C2=A0=C2=A0=C2=A0 }<br></div><div>=C2=A0 };<br></div><div><br></div></div>=
</div></div></blockquote></div></div><div><br></div>Presumably, this is if =
there is a private lvalue being returned:<div><br></div><div>struct Foo</di=
v><div>{</div><div>
=C2=A0 =C2=A0 T& getFoo() { return foo; }</div><div>=C2=A0 =C2=A0 const=
T& getFoo() const { return foo; }<br></div><div><br></div><div>private=
:</div><div><br></div><div>=C2=A0 =C2=A0 T foo;</div><div>};</div><div><br>=
</div><div>I still suspect needing as_const is indicative of a design flaw =
in the surrounding code.<br>
</div><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 <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 />
--90e6ba1811d6c2f2980500f471d2--
.
Author: Jonathan Coe <jonathanbcoe@gmail.com>
Date: Tue, 19 Aug 2014 07:11:40 +0100
Raw View
--Apple-Mail-F1A1B890-DAD1-4851-8EDC-2EB11E01859E
Content-Type: text/plain; charset=ISO-8859-1
> On 19 Aug 2014, at 03:58, Greg Marr <gregmmarr@gmail.com> wrote:
>
> \On Saturday, August 16, 2014 7:05:41 AM UTC-4, Jonathan Coe wrote:
>>
>> Sometimes it's desirable to use const methods on a non-const object.
>> This can be done with const_cast, but const_cast can equally well be used to do potentially unsafe things and is often flagged up in code reviews or banned outright by coding standards/pre-commit scripts.
>
> What am I missing here? You can already use const methods on non-const objects without a cast. Are you trying to select a const overload in favor of a non-const overload?
>
Yes.
> --
>
> ---
> 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/.
--
---
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-F1A1B890-DAD1-4851-8EDC-2EB11E01859E
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><br></div><div><br>On 19 Aug 2014,=
at 03:58, Greg Marr <<a href=3D"mailto:gregmmarr@gmail.com">gregmmarr@g=
mail.com</a>> wrote:<br><br></div><blockquote type=3D"cite"><div><div di=
r=3D"ltr">\On Saturday, August 16, 2014 7:05:41 AM UTC-4, Jonathan Coe wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Sometimes i=
t's desirable to use const methods on a non-const object.<div>This can be d=
one with const_cast, but const_cast can equally well be used to do potentia=
lly unsafe things and is often flagged up in code reviews or banned outrigh=
t by coding standards/pre-commit scripts.</div></div></blockquote><div><br>=
</div><div>What am I missing here? You can already use const methods =
on non-const objects without a cast. Are you trying to select a const=
overload in favor of a non-const overload?</div><div><br></div></div></div=
></blockquote><div><br></div>Yes. <br><blockquote type=3D"cite"><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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br>
</div></blockquote></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-F1A1B890-DAD1-4851-8EDC-2EB11E01859E--
.
Author: Myriachan <myriachan@gmail.com>
Date: Tue, 19 Aug 2014 12:25:33 -0700 (PDT)
Raw View
------=_Part_1146_1551676972.1408476333900
Content-Type: text/plain; charset=UTF-8
On Monday, August 18, 2014 8:12:57 PM UTC-7, Andrew Tomazos wrote:
>
> On Tue, Aug 19, 2014 at 4:58 AM, Greg Marr <greg...@gmail.com
> <javascript:>> wrote:
>
>> What am I missing here? You can already use const methods on non-const
>> objects without a cast. Are you trying to select a const overload in favor
>> of a non-const overload?
>>
>
> I share your skepticism, and am still waiting for a motivating code
> example of where as_const is needed.
>
Linked list iterators can be more complicated if they have to account for
the possibility of list elements being deleted during the current
iteration. If you want to iterate a linked list, and don't need to change
anything in the list, but you're in a non-const context for that list, you
would get a slight performance boost from static_casting the list to const
type--or using this proposed std::as_const. cbegin and cend work, but not
with C++11 "for each" syntax, right?
On Monday, August 18, 2014 8:08:49 PM UTC-7, Tom Honermann wrote:
>
> On 08/18/2014 10:14 PM, Myriachan wrote:
>
> On Monday, August 18, 2014 1:11:26 AM UTC-7, vadim.pet...@gmail.com
> wrote:
>>
>> >as_signed sounds like a recipe for overflow
>>
>> No more than any other signed arithmetic.
>> A typical example of use:
>>
>>
> These are very problematic. Let's say you wrote code like this:
>
> // Make sure that this multiplication is unsigned so that when it
> overflows,
> // it is well-defined as wrapping around.
> template <typename X>
> X wrap_square(X x)
> {
> return static_cast<X>(as_unsigned(x) * as_unsigned(x));
> }
>
> ...except that this is wrong: it has undefined behavior on 32-bit machines
> when X is std::uint16_t. Despite the attempt at doing unsigned arithmetic,
> it still is doing signed arithmetic. Worse yet, this is platform-specific.
>
>
> Would it be terrible if as_unsigned() implicitly applied promotions?
> Alternatively, as_unsigned_promoted(x).
>
> Tom.
>
How would this work? The promoted type of std::uint16_t on 32-bit
platforms is signed int, hence the current insanity. We'd want
as_unsigned_promoted<std::uint16_t> to return unsigned int?
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_1146_1551676972.1408476333900
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 18, 2014 8:12:57 PM UTC-7, Andrew Tomazo=
s 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"><div>=
<div class=3D"gmail_quote">On Tue, Aug 19, 2014 at 4:58 AM, Greg Marr <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"QPYwV90mdjwJ" onmousedown=3D"this.href=3D'javascript:';return true=
;" onclick=3D"this.href=3D'javascript:';return true;">greg...@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 dir=3D"ltr">What am I missing here? &nb=
sp;You can already use const methods on non-const objects without a cast. &=
nbsp;Are you trying to select a const overload in favor of a non-const over=
load?
<div></div></div></blockquote></div><br></div><div>I share your skepticism,=
and am still waiting for a motivating code example of where as_const is ne=
eded.</div></div></blockquote><div><br>Linked list iterators can be more co=
mplicated if they have to account for the possibility of list elements bein=
g deleted during the current iteration. If you want to iterate a link=
ed list, and don't need to change anything in the list, but you're in a non=
-<span style=3D"font-family: courier new,monospace;">const</span> context f=
or that list, you would get a slight performance boost from <span style=3D"=
font-family: courier new,monospace;">static_cast</span>ing the list to <spa=
n style=3D"font-family: courier new,monospace;">const</span> type--or using=
this proposed <span style=3D"font-family: courier new,monospace;">std::as_=
const</span>. <span style=3D"font-family: courier new,monospace;">cbe=
gin</span> and <span style=3D"font-family: courier new,monospace;">cend</sp=
an> work, but not with C++11 "<span style=3D"font-family: courier new,monos=
pace;">for</span> each" syntax, right?<br><br><br>On Monday, August 18, 201=
4 8:08:49 PM UTC-7, Tom Honermann wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF">
On 08/18/2014 10:14 PM, Myriachan wrote:<br>
<blockquote type=3D"cite">
=20
<div dir=3D"ltr">On Monday, August 18, 2014 1:11:26 AM UTC-7,
<a>vadim.pet...@gmail.com</a> wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">
<div>>as_signed sounds like a recipe for overflow</div>
<div><br>
</div>
<div>No more than any other signed arithmetic.</div>
<div>A typical example of use:</div>
<br>
</div>
</blockquote>
<div><br>
These are very problematic. Let's say you wrote code like
this:<br>
<br>
<div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e>
<div><span style=3D"color:#800">// Make sure that this
multiplication is unsigned so that when it overflows,</sp=
an><span style=3D"color:#000"><br>
</span><span style=3D"color:#800">// it is well-defined as
wrapping around.</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#008">template</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660"><</span><span style=
=3D"color:#008">typename</span><span style=3D"color:#000"> X</span><span st=
yle=3D"color:#660">></span><span style=3D"color:#000"><br>
X wrap_square</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#000">X x</span><span style=3D"color:#660">)</span><span=
style=3D"color:#000"><br>
</span><span style=3D"color:#660">{</span><span style=3D"co=
lor:#000"><br>
</span><span style=3D"color:#008">return</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#008">static_ca=
st</span><span style=3D"color:#660"><</span><span style=3D"color:#000">X=
</span><span style=3D"color:#660">>(</span><span style=3D"color:#000">as=
_unsigned</span><span style=3D"color:#660">(</span><span style=3D"color:#00=
0">x</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">*</span><span style=3D"color:#000">
as_unsigned</span><span style=3D"color:#660">(</span><spa=
n style=3D"color:#000">x</span><span style=3D"color:#660">));</span><span s=
tyle=3D"color:#000"><br>
</span><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br>
</span></div>
</code></div>
<br>
...except that this is wrong: it has undefined behavior on
32-bit machines when X is std::uint16_t. Despite the attemp=
t
at doing unsigned arithmetic, it still is doing signed
arithmetic. Worse yet, this is platform-specific.<br>
</div>
</div>
</blockquote>
<br>
Would it be terrible if as_unsigned() implicitly applied
promotions? Alternatively, as_unsigned_promoted(x). <br>
<br>
Tom.<br></div></blockquote><br>How would this work? The promoted =
type of <span style=3D"font-family: courier new,monospace;">std::uint16_t</=
span> on 32-bit platforms is <span style=3D"font-family: courier new,monosp=
ace;">signed int</span>, hence the current insanity. We'd want <span =
style=3D"font-family: courier new,monospace;">as_unsigned_promoted<std::=
uint16_t></span> to return <span style=3D"font-family: courier new,monos=
pace;">unsigned int</span>?<br><br>Melissa<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_1146_1551676972.1408476333900--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 19 Aug 2014 14:45:11 -0500
Raw View
--f46d044280c421c263050100bc77
Content-Type: text/plain; charset=UTF-8
On 19 August 2014 14:25, Myriachan <myriachan@gmail.com> wrote:
> On Monday, August 18, 2014 8:12:57 PM UTC-7, Andrew Tomazos wrote:
>
>> On Tue, Aug 19, 2014 at 4:58 AM, Greg Marr <greg...@gmail.com> wrote:
>>
>>> What am I missing here? You can already use const methods on non-const
>>> objects without a cast. Are you trying to select a const overload in favor
>>> of a non-const overload?
>>>
>>
>> I share your skepticism, and am still waiting for a motivating code
>> example of where as_const is needed.
>>
>
> Linked list iterators can be more complicated if they have to account for
> the possibility of list elements being deleted during the current
> iteration.
>
I do not believe that is a requirement of any iterator in the standard
library. Sure, you might have a debugging library which does that, but
performance considerations and debugging library typically don't go
together.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
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/.
--f46d044280c421c263050100bc77
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 August 2014 14:25, Myriachan <span dir=3D"ltr"><<=
a href=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@gmail.com=
</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_qu=
ote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">On Monday, August 18, 2014 8:12:57 PM UTC-7, Andrew Tomazo=
s wrote:<div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">
<div><div class=3D"gmail_quote">On Tue, Aug 19, 2014 at 4:58 AM, Greg Marr =
<span dir=3D"ltr"><<a>greg...@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 dir=3D"ltr">What am I missing here? =C2=
=A0You can already use const methods on non-const objects without a cast. =
=C2=A0Are you trying to select a const overload in favor of a non-const ove=
rload?
<div></div></div></blockquote></div><br></div><div>I share your skepticism,=
and am still waiting for a motivating code example of where as_const is ne=
eded.</div></div></blockquote></div><div><br>Linked list iterators can be m=
ore complicated if they have to account for the possibility of list element=
s being deleted during the current iteration.=C2=A0</div>
</div></blockquote><div><br></div><div>I do not believe that is a requireme=
nt of any iterator in the standard library.=C2=A0 Sure, you might have a de=
bugging library which does that, but performance considerations and debuggi=
ng library typically don't go together.<br>
</div></div>-- <br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a hr=
ef=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.c=
om</a>>=C2=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404=
" target=3D"_blank">(847) 691-1404</a>
</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 />
--f46d044280c421c263050100bc77--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Tue, 19 Aug 2014 21:45:06 -0400
Raw View
On 08/19/2014 03:25 PM, Myriachan wrote:
> On Monday, August 18, 2014 8:08:49 PM UTC-7, Tom Honermann wrote:
>
> On 08/18/2014 10:14 PM, Myriachan wrote:
>> On Monday, August 18, 2014 1:11:26 AM UTC-7,
>> vadim.pet...@gmail.com wrote:
>>
>> >as_signed sounds like a recipe for overflow
>>
>> No more than any other signed arithmetic.
>> A typical example of use:
>>
>>
>> These are very problematic. Let's say you wrote code like this:
>>
>> |
>> // Make sure that this multiplication is unsigned so that when it
>> overflows,
>> // it is well-defined as wrapping around.
>> template<typenameX>
>> X wrap_square(X x)
>> {
>> return static_cast<X>(as_unsigned(x)*as_unsigned(x));
>> }
>> |
>>
>> ...except that this is wrong: it has undefined behavior on 32-bit
>> machines when X is std::uint16_t. Despite the attempt at doing
>> unsigned arithmetic, it still is doing signed arithmetic. Worse
>> yet, this is platform-specific.
>
> Would it be terrible if as_unsigned() implicitly applied
> promotions? Alternatively, as_unsigned_promoted(x).
>
> Tom.
>
>
> How would this work? The promoted type of std::uint16_t on 32-bit
> platforms is signed int, hence the current insanity. We'd want
> as_unsigned_promoted<std::uint16_t> to return unsigned int?
Exactly. I'm not saying it is necessarily a good idea, but I believe it
would address the undefined behavior in the above test case.
Tom.
--
---
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: Wed, 20 Aug 2014 10:28:39 +0800
Raw View
--Apple-Mail=_87E654A9-4258-4EE8-B41E-0123354C72D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-20, at 9:45 AM, Tom Honermann <thonermann@coverity.com> wrote:
> Exactly. I'm not saying it is necessarily a good idea, but I believe it =
would address the undefined behavior in the above test case.
Usual arithmetic conversions are not a defense against overflow. The rule i=
s designed to help the language model CPUs that only perform computations a=
t the width of the ALU. The idea is that the machine ABI sets int to the wi=
dth of the ALU, and then fewer bit-masking operations are required. On a 16=
-bit machine, or a 32-bit architecture supporting 16-bit operations such as=
M68K, int is not likely to be wider than int16_t. (On an 8-bit machine, th=
is is also true, and furthermore by-default arithmetic promotion may be cou=
nterproductive as the result is wider than the ALU, such that the optimizer=
must "undo" it when it is unconditionally narrowed again.)
I can see a function like promote() being helpful only because implicit pro=
motion is a bear for generic numerics. Few people ever code that carefully =
though, and it's easy enough to define for yourself, or to annotate such ex=
pressions with the unary + operator.
--=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=_87E654A9-4258-4EE8-B41E-0123354C72D8
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 2014&=
ndash;08–20, at 9:45 AM, Tom Honermann <<a href=3D"mailto:thonerma=
nn@coverity.com">thonermann@coverity.com</a>> wrote:</div><br class=3D"A=
pple-interchange-newline"><blockquote type=3D"cite">Exactly. I'm not =
saying it is necessarily a good idea, but I believe it would address the un=
defined behavior in the above test case.<br></blockquote></div><br><div>Usu=
al arithmetic conversions are not a defense against overflow. The rule is d=
esigned to help the language model CPUs that only perform computations at t=
he width of the ALU. The idea is that the machine ABI sets <font face=3D"Co=
urier">int</font> to the width of the ALU, and then fewer bit-masking opera=
tions are required. On a 16-bit machine, or a 32-bit architecture supportin=
g 16-bit operations such as M68K, <font face=3D"Courier">int</font> is not =
likely to be wider than <font face=3D"Courier">int16_t</font>. (On an 8-bit=
machine, this is also true, and furthermore by-default arithmetic promotio=
n may be counterproductive as the result is wider than the ALU, such that t=
he optimizer must “undo” it when it is unconditionally narrowed=
again.)</div><div><br></div><div>I can see a function like <font face=3D"C=
ourier">promote()</font> being helpful only because implicit promotion is a=
bear for generic numerics. Few people ever code that carefully though, and=
it’s easy enough to define for yourself, or to annotate such express=
ions with the unary + operator.</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 <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=_87E654A9-4258-4EE8-B41E-0123354C72D8--
.
Author: Tom Honermann <thonermann@coverity.com>
Date: Wed, 20 Aug 2014 10:14:43 -0400
Raw View
On 08/19/2014 10:28 PM, David Krauss wrote:
>
> On 2014-08-20, at 9:45 AM, Tom Honermann <thonermann@coverity.com
> <mailto:thonermann@coverity.com>> wrote:
>
>> Exactly. I'm not saying it is necessarily a good idea, but I believe
>> it would address the undefined behavior in the above test case.
>
> Usual arithmetic conversions are not a defense against overflow.
The suggestion wasn't intended to aid in defense against overflow, but
rather to avoid undefined behavior when an overflow occurs. The example
that Melissa provided included this comment:
// Make sure that this multiplication is unsigned so that when it
overflows,
// it is well-defined as wrapping around.
> I can see a function like promote() being helpful only because implicit
> promotion is a bear for generic numerics. Few people ever code that
> carefully though, and it's easy enough to define for yourself, or to
> annotate such expressions with the unary + operator.
Agreed. The suggested as_unsigned_promoted(x) could then be replaced
by, or implemented as, as_unsigned(promoted(x)). I think the utility of
this is limited by the fact that one needs to understand promotion rules
and undefined behavior with respect to signed arithmetic in order to
know when to protect against unintended behavior. In other words, it
probably doesn't help people from writing incorrect code in the first
place (though its use *might* help to prevent introducing bugs during
maintenance).
Tom.
--
---
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: Zhihao Yuan <zy@miator.net>
Date: Wed, 20 Aug 2014 21:29:10 -0400
Raw View
--e0cb4e887c09c49c0d050119a542
Content-Type: text/plain; charset=UTF-8
On Tue, Aug 19, 2014 at 1:06 AM, Andrew Tomazos <andrewtomazos@gmail.com>
wrote:
>
> for (x : as_const(v))
>> {
>> // got x from begin const / end const
>> }
>>
>
> I think this is better:
>
> for (const auto& x : v) { ... }
>
> But STL also has this in the works:
>
> for (const x : v) { ... }
>
There is a difference. In your example, the iteration is still taken on
the iterator, but my example give you const_iterator -- they are not
required to be different only by qualification! Even in a standard library,
they can be unrelated types in debug mode for catch more iterator bugs.
And I assume that's one of the reason why such a syntax is not
proposed in STL's paper.
> Also, if v is a temporary, will your version be lifetime extended?
>
Yes. as_const(v) does not put v out of full expression.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://bit.ly/blog4bsd
--
---
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/.
--e0cb4e887c09c49c0d050119a542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tue, Aug 19, 2014 at 1:06 AM, Andrew Tomazos <span dir=
=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">a=
ndrewtomazos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D""><br><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c=
olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>=C2=A0 for (x : as_const(v))<br>=C2=A0 {<br></div><div>=C2=A0=C2=A0=C2=A0 =
// got x from begin const / end const<br></div><div>=C2=A0 }<br></div></div=
></div></div></blockquote><div><br>
</div></div><div>I think this is better:</div>
<div><br></div><div>=C2=A0 =C2=A0for (const auto& x : v) { ... }</div><=
div><br></div><div>But STL also has this in the works:</div><div><br></div>=
<div>=C2=A0 =C2=A0for (const x : v) { ... }</div></div></div></div></blockq=
uote><div><br></div>
<div>There is a difference.=C2=A0 In your example, the iteration is still t=
aken on<br></div><div>the iterator, but my example give you const_iterator =
-- they are not<br></div><div>required to be different only by qualificatio=
n!=C2=A0 Even in a standard library,<br>
they can be unrelated types in debug mode for catch more iterator bugs.<br>=
<br></div><div>And I assume that's one of the reason why such a syntax =
is not<br>proposed in STL's paper.<br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
><br></div><div>Also, if v is a temporary, will your version be lifetime ex=
tended?<br></div></div></div></div></blockquote><div><br></div><div>Yes.=C2=
=A0 as_const(v) does not put v out of full expression.<br>
</div></div><br>-- <br>Zhihao Yuan, ID lichray<br>The best way to predict t=
he future is to invent it.<br>_____________________________________________=
______<br>4BSD -- <a href=3D"http://bit.ly/blog4bsd" target=3D"_blank">http=
://bit.ly/blog4bsd</a>
</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 />
--e0cb4e887c09c49c0d050119a542--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Wed, 20 Aug 2014 22:43:39 -0500
Raw View
On Wednesday 20 August 2014 21:29:10 Zhihao Yuan wrote:
> > I think this is better:
> > for (const auto& x : v) { ... }
> >
> > But STL also has this in the works:
> > for (const x : v) { ... }
>
> There is a difference. In your example, the iteration is still taken on
> the iterator, but my example give you const_iterator -- they are not
> required to be different only by qualification! Even in a standard library,
> they can be unrelated types in debug mode for catch more iterator bugs.
>
> And I assume that's one of the reason why such a syntax is not
> proposed in STL's paper.
For Qt containers, that would be important. The range for calls std::begin()
on the container and the non-const overload of the member begin() will try to
implicitly detach the container. If you don't plan on modifying the container,
you'll want to call the const versions instead which you could do by using
for (auto x : as_const(v))
> > Also, if v is a temporary, will your version be lifetime extended?
>
> Yes. as_const(v) does not put v out of full expression.
When I was trying to rewrite Qt's foreach() macro with the C++11 range for, I
ran into exactly that problem: the lifetime of the temporary was too short.
But I could never prove or disprove whether this was a compiler bug, a mistake
in my macro or required behaviour as per the standard...
--
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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 21 Aug 2014 09:16:52 +0300
Raw View
On 21 August 2014 06:43, Thiago Macieira <thiago@macieira.org> wrote:
>> > Also, if v is a temporary, will your version be lifetime extended?
>> Yes. as_const(v) does not put v out of full expression.
> When I was trying to rewrite Qt's foreach() macro with the C++11 range for, I
> ran into exactly that problem: the lifetime of the temporary was too short.
> But I could never prove or disprove whether this was a compiler bug, a mistake
> in my macro or required behaviour as per the standard...
Perhaps you ran into this:
http://cplusplus.github.io/EWG/ewg-active.html#120
--
---
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: Thu, 21 Aug 2014 16:07:03 +0800
Raw View
--Apple-Mail=_3C8D78E4-E2D8-40EE-B14A-7E9D0748BB6D
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-21, at 2:16 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 21 August 2014 06:43, Thiago Macieira <thiago@macieira.org> wrote:
>>>> Also, if v is a temporary, will your version be lifetime extended?
>>> Yes. as_const(v) does not put v out of full expression.
>> When I was trying to rewrite Qt's foreach() macro with the C++11 range for, I
>> ran into exactly that problem: the lifetime of the temporary was too short.
>> But I could never prove or disprove whether this was a compiler bug, a mistake
>> in my macro or required behaviour as per the standard...
>
> Perhaps you ran into this:
> http://cplusplus.github.io/EWG/ewg-active.html#120
This has nothing to do with constness.
It looks to me like a design flaw in Boost. The adaptors are not designed to compose, yet the syntax they chose allows well-formed expressions that fail at runtime. It would have been safer if they'd put the adaptors on the LHS:
boost::adaptors::reversed |
boost::adaptors::uniqued | vec
Then the library designer chooses between reporting an error because the adaptor was applied to something besides a container, or allowing adaptors to functionally compose before application to the container.
The as_const problem at hand is easily solved by overloading the factory function on rvalues, using return by value.
template< typename type >
type const & as_const( type const & ref )
{ return ref; }
template< typename type >
std::enable_if_t< ! std::is_reference_v< type >,
type const > as_const( type && val )
{ return std::move( val ); }
Demo: http://ideone.com/fC3cGq
If Boost were to apply this, they would need the adaptor to support both reference-proxy and proper adaptor semantics. It doesn't sound like too much to ask of them.
--
---
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=_3C8D78E4-E2D8-40EE-B14A-7E9D0748BB6D
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 2014&=
ndash;08–21, at 2:16 PM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 21 Augus=
t 2014 06:43, Thiago Macieira <<a href=3D"mailto:thiago@macieira.org">th=
iago@macieira.org</a>> wrote:<br><blockquote type=3D"cite"><blockquote t=
ype=3D"cite"><blockquote type=3D"cite">Also, if v is a temporary, will your=
version be lifetime extended?<br></blockquote>Yes. as_const(v) does =
not put v out of full expression.<br></blockquote>When I was trying to rewr=
ite Qt's foreach() macro with the C++11 range for, I<br>ran into exactly th=
at problem: the lifetime of the temporary was too short.<br>But I could nev=
er prove or disprove whether this was a compiler bug, a mistake<br>in my ma=
cro or required behaviour as per the standard...<br></blockquote><br>Perhap=
s you ran into this:<br><a href=3D"http://cplusplus.github.io/EWG/ewg-activ=
e.html#120">http://cplusplus.github.io/EWG/ewg-active.html#120</a><br></blo=
ckquote><div><br></div></div>This has nothing to do with constness.<div><br=
></div><div>It looks to me like a design flaw in Boost. The adaptors are no=
t designed to compose, yet the syntax they chose allows well-formed express=
ions that fail at runtime. It would have been safer if they’d put the=
adaptors on the LHS:</div><div><pre><code>boost::adaptors::reversed |
boost::adaptors::uniqued | vec</code></pre><div>Then the library designer =
chooses between reporting an error because the adaptor was applied to somet=
hing besides a container, or allowing adaptors to functionally compose befo=
re application to the container.</div></div><div><br></div><div>The <font f=
ace=3D"Courier">as_const</font> problem at hand is easily solved by overloa=
ding the factory function on rvalues, using return by value.</div><div><br>=
</div><div><div><font face=3D"Courier">template< typename type=
><br></font></div><div><font face=3D"Courier">type const =
;& as_const( type const & ref )<br></=
font></div><div><font face=3D"Courier"> { return&nbs=
p;ref; }<br></font></div><div><font face=3D"Courier"> <br></font>=
</div><div><font face=3D"Courier">template< typename type =
;><br></font></div><div><font face=3D"Courier">std::enable_if_t< =
;! std::is_reference_v< type >,<br></font></div><div><=
font face=3D"Courier">type</font><span style=3D"font-family: Courier;">&nbs=
p;</span><span style=3D"font-family: Courier;">const</span><span style=3D"f=
ont-family: Courier;"> </span><span style=3D"font-family: Courier;">&g=
t;</span><span style=3D"font-family: Courier;"> as_const</span><span s=
tyle=3D"font-family: Courier;">(</span><span style=3D"font-family: Courier;=
"> type </span><span style=3D"font-family: Courier;">&&</=
span><span style=3D"font-family: Courier;"> val </span><span styl=
e=3D"font-family: Courier;">)</span></div><div><font face=3D"Courier"> =
; { return std::move( val ); }<br></font></d=
iv><div><br></div></div><div>Demo: <a href=3D"http://ideone.com/fC3cGq">htt=
p://ideone.com/fC3cGq</a></div><div><br></div><div>If Boost were to apply t=
his, they would need the adaptor to support both reference-proxy and proper=
adaptor semantics. It doesn’t sound like too much to ask of them.</d=
iv><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_3C8D78E4-E2D8-40EE-B14A-7E9D0748BB6D--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 21 Aug 2014 11:52:30 +0300
Raw View
On 21 August 2014 11:07, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9321, at 2:16 PM, Ville Voutilainen <ville.vouti=
lainen@gmail.com>
> wrote:
>
> On 21 August 2014 06:43, Thiago Macieira <thiago@macieira.org> wrote:
>
> Also, if v is a temporary, will your version be lifetime extended?
>
> Yes. as_const(v) does not put v out of full expression.
>
> When I was trying to rewrite Qt's foreach() macro with the C++11 range fo=
r,
> I
> ran into exactly that problem: the lifetime of the temporary was too shor=
t.
> But I could never prove or disprove whether this was a compiler bug, a
> mistake
> in my macro or required behaviour as per the standard...
>
>
> Perhaps you ran into this:
> http://cplusplus.github.io/EWG/ewg-active.html#120
>
>
> This has nothing to do with constness.
Nobody said it does.
>
> It looks to me like a design flaw in Boost. The adaptors are not designed=
to
> compose, yet the syntax they chose allows well-formed expressions that fa=
il
That's news to me.
> The as_const problem at hand is easily solved by overloading the factory
> function on rvalues, using return by value.
That will not help with the lifetime issue.
--=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: David Krauss <potswa@gmail.com>
Date: Thu, 21 Aug 2014 21:00:17 +0800
Raw View
--Apple-Mail=_34992428-1760-4646-9FF7-269A0BD32BC7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-21, at 4:52 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:
> Nobody said it does.
Still worth mentioning.
>> It looks to me like a design flaw in Boost. The adaptors are not designe=
d to
>> compose, yet the syntax they chose allows well-formed expressions that f=
ail
>=20
> That's news to me.
???
It's just advice to anyone designing a similar facility. If composition is =
going to be a special feature, then put the operand on the RHS. This partic=
ular problem with that Boost library appears to have been there since there=
were two adaptors to compose. It's not an interaction with C++11 or anythi=
ng, and it was avoidable at the time the operator overloads were conceived.
>> The as_const problem at hand is easily solved by overloading the factory
>> function on rvalues, using return by value.
>=20
> That will not help with the lifetime issue.
Sure it does, see the demo. as_const works with lvalues and rvalues alike.
(It's not a factory function in this case, that was just an editing error. =
The sentence was originally written to refer to Boost. As for them, the bug=
linked from the EWG issue shows a similar approach to the lifetime issue, =
as I described. They only seem to be stuck in choosing between improved eff=
iciency by letting owning and non-owning adaptors be different types, or im=
proved compatibility by letting them be the same type with a runtime switch=
.. Nobody there seems to be asking for a new core language feature.)
--=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=_34992428-1760-4646-9FF7-269A0BD32BC7
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 2014&=
ndash;08–21, at 4:52 PM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=
=3D"font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Nobody sai=
d it does.<br></div></blockquote><div><br></div>Still worth mentioning.</di=
v><div><br><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;"><blockquote type=3D"cite">It looks to =
me like a design flaw in Boost. The adaptors are not designed to<br>compose=
, yet the syntax they chose allows well-formed expressions that fail<br></b=
lockquote><br>That's news to me.<br></div></blockquote><div><br></div><div>=
???</div><div><br></div><div>It’s just advice to anyone designing a s=
imilar facility. If composition is going to be a special feature, then put =
the operand on the RHS. This particular problem with that Boost library app=
ears to have been there since there were two adaptors to compose. It’=
s not an interaction with C++11 or anything, and it was avoidable at the ti=
me the operator overloads were conceived.</div><br><blockquote type=3D"cite=
"><div style=3D"font-size: 12px; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; orphans: =
auto; text-align: start; text-indent: 0px; text-transform: none; white-spac=
e: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;=
"><blockquote type=3D"cite">The as_const problem at hand is easily solved b=
y overloading the factory<br>function on rvalues, using return by value.<br=
></blockquote><br>That will not help with the lifetime issue.<br></div></bl=
ockquote><div><br></div>Sure it does, see the demo. <font face=3D"Courier">=
as_const</font> works with lvalues and rvalues alike.</div><div><br></div><=
div>(It’s not a factory function in this case, that was just an editi=
ng error. The sentence was originally written to refer to Boost. As for the=
m, the bug linked from the EWG issue shows a similar approach to the lifeti=
me issue, as I described. They only seem to be stuck in choosing between im=
proved efficiency by letting owning and non-owning adaptors be different ty=
pes, or improved compatibility by letting them be the same type with a runt=
ime switch. Nobody there seems to be asking for a new core language feature=
..)</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=_34992428-1760-4646-9FF7-269A0BD32BC7--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 21 Aug 2014 16:20:49 +0300
Raw View
On 21 August 2014 16:00, David Krauss <potswa@gmail.com> wrote:
>>> It looks to me like a design flaw in Boost. The adaptors are not designed to
>>> compose, yet the syntax they chose allows well-formed expressions that fail
>> That's news to me.
> ???
It's news to me that those adaptors are not designed to compose, yes.
>>> The as_const problem at hand is easily solved by overloading the factory
>>> function on rvalues, using return by value.
>> That will not help with the lifetime issue.
> Sure it does, see the demo. as_const works with lvalues and rvalues alike.
No it doesn't, if you combine as_const with other expressions, as EWG 120
illustrates. The subexpression temporaries are gone by the time the loop is
entered, even if the temporary in the full expression gets a lifetime extension.
Whether that's worth fixing is another matter.
--
---
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: Thu, 21 Aug 2014 21:34:22 +0800
Raw View
--Apple-Mail=_140DF9B7-E0EC-4B46-A49A-C06546489ACB
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-21, at 9:20 PM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> It's news to me that those adaptors are not designed to compose, yes.
The adaptor templates themselves do compose, but not by the factory functions implemented by operator overloading. The associativity of the operators is what's causing a problem here; that is my point.
>>>> The as_const problem at hand is easily solved by overloading the factory
>>>> function on rvalues, using return by value.
>>> That will not help with the lifetime issue.
>> Sure it does, see the demo. as_const works with lvalues and rvalues alike.
>
> No it doesn't, if you combine as_const with other expressions, as EWG 120
> illustrates. The subexpression temporaries are gone by the time the loop is
> entered, even if the temporary in the full expression gets a lifetime extension.
> Whether that's worth fixing is another matter.
You can pass as_const to itself with no ill effects, or other functions that return by value.
Taking an rvalue reference parameter and returning some part of it by soon-to-be-dangling reference is a bad idea. Using return by value in such cases is a teachable rule to avoid a lot of headaches. But, we've recently had this discussion already.
--
---
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=_140DF9B7-E0EC-4B46-A49A-C06546489ACB
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 2014&=
ndash;08–21, at 9:20 PM, Ville Voutilainen <<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">It's news t=
o me that those adaptors are not designed to compose, yes.<br></blockquote>=
<div><br></div><div>The adaptor templates themselves do compose, but not by=
the factory functions implemented by operator overloading. The associativi=
ty of the operators is what’s causing a problem here; that is my poin=
t.</div><br><blockquote type=3D"cite"><blockquote type=3D"cite"><blockquote=
type=3D"cite"><blockquote type=3D"cite">The as_const problem at hand is ea=
sily solved by overloading the factory<br>function on rvalues, using return=
by value.<br></blockquote>That will not help with the lifetime issue.<br><=
/blockquote>Sure it does, see the demo. as_const works with lvalues and rva=
lues alike.<br></blockquote><br>No it doesn't, if you combine as_const with=
other expressions, as EWG 120<br>illustrates. The subexpression temporarie=
s are gone by the time the loop is<br>entered, even if the temporary in the=
full expression gets a lifetime extension.<br>Whether that's worth fixing =
is another matter.<br></blockquote><div><br></div></div><div>You can pass <=
font face=3D"Courier">as_const</font> to itself with no ill effects, or oth=
er functions that return by value.</div><div><br></div><div>Taking an rvalu=
e reference parameter and returning some part of it by soon-to-be-dangling =
reference is a bad idea. Using return by value in such cases is a teachable=
rule to avoid a lot of headaches. But, we’ve recently had this discu=
ssion already.</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 <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=_140DF9B7-E0EC-4B46-A49A-C06546489ACB--
.
Author: Scott Prager <splinterofchaos@gmail.com>
Date: Sun, 31 Aug 2014 20:56:50 -0700 (PDT)
Raw View
------=_Part_307_705486227.1409543810232
Content-Type: text/plain; charset=UTF-8
Coming into this conversation late, but...
On Monday, August 18, 2014 11:59:38 PM UTC-4, Zhihao Yuan wrote:
struct Foo
> {
> T& foo()
> {
> // maybe more useful with as_non_const?
> return const_cast<T&>(as_const(*this).foo());
> }
>
> T const& foo() const
> {
> // ...
> }
> };
>
The problem I've always had with using the const version in the non-const
overload is
having to make it so verbose when it does something so simple. I'd much
prefer something
like (pseudo-code):
T& foo() {
// implicitly un-const the result
return as_const_apply(&Foo::foo, *this);
}
because I really only want to write const one time.
--
---
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_307_705486227.1409543810232
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Coming into this conversation late, but...<br><br>On Monda=
y, August 18, 2014 11:59:38 PM UTC-4, Zhihao Yuan wrote:<div><br><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div> struct Foo<br> {<br></div><div>  =
; T& foo()<br> {<br>
</div><div> // maybe more useful with as_non_=
const?<br></div><div> return const_cast<T&=
amp;>(as_const(*this)<wbr>.foo());<br></div><div> }<br=
><br></div><div> T const& foo() const<br> =
{<br> // ...<br>
}<br></div><div> };</div></div></div></div></block=
quote><div><br></div><div>The problem I've always had with using the const =
version in the non-const overload is </div><div>having to make it so v=
erbose when it does something so simple. I'd much prefer something</div></d=
iv><div>like (pseudo-code):</div><div><br></div><div><div> T&a=
mp; foo() {</div><div> // implicitly un-const the =
result</div><div> return as_const_apply(&=
Foo::foo, *this);<br></div><div> }</div></div><div><br></=
div><div>because I really only want to write const one time.</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_307_705486227.1409543810232--
.
Author: Sebastian Redl <wasti.redl@gmx.net>
Date: Tue, 9 Sep 2014 15:24:28 -0700 (PDT)
Raw View
------=_Part_759_1034613467.1410301468455
Content-Type: text/plain; charset=UTF-8
On Saturday, August 16, 2014 10:46:45 PM UTC+2, Andrew Tomazos wrote:
>
> On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe <jonath...@gmail.com
> <javascript:>> wrote:
>
>> Sometimes it's desirable to use const methods on a non-const object.
>>
>
> For example?
>
>
I used a function like as_const (except I called it const_) when
implementing generic algorithms that called back into user code, when I
wanted to ensure that user code couldn't do really stupid stuff like
modifying in a predicate:
template <typename It, typename Pred>
bool any(It first, It last, Pred p) {
for (; first != last; ++first) {
if (p(as_const(*first))) return true;
}
return false;
}
I like the idea that the template implementation stops the predicate from
modifying the elements even if the iterators allow mutation.
Sebastian
--
---
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_759_1034613467.1410301468455
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, August 16, 2014 10:46:45 PM UTC+2, Andrew Tom=
azos 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"><d=
iv><div class=3D"gmail_quote">On Sat, Aug 16, 2014 at 1:05 PM, Jonathan Coe=
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"hc8D_ve-1ksJ" onmousedown=3D"this.href=3D'javascript:';retur=
n true;" onclick=3D"this.href=3D'javascript:';return true;">jonath...@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 dir=3D"ltr">Sometimes it's desirable to=
use const methods on a non-const object.<div></div></div></blockquote></di=
v>
<br></div><div>For example?</div><div><br></div></div></blockquote><div><br=
>I used a function like as_const (except I called it const_) when imp=
lementing generic algorithms that called back into user code, when I wanted=
to ensure that user code couldn't do really stupid stuff like modifying in=
a predicate:<br><br>template <typename It, typename Pred><br>bool an=
y(It first, It last, Pred p) {<br> for (; first !=3D last; ++first) {=
<br> if (p(as_const(*first))) return true;<br> }<br=
> return false;<br>}<br><br>I like the idea that the template impleme=
ntation stops the predicate from modifying the elements even if the iterato=
rs allow mutation.<br><br>Sebastian<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_759_1034613467.1410301468455--
.
Author: Sebastian Redl <wasti.redl@gmx.net>
Date: Tue, 9 Sep 2014 15:29:48 -0700 (PDT)
Raw View
------=_Part_248_1644221527.1410301788461
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, August 21, 2014 10:07:21 AM UTC+2, David Krauss wrote:
>
> It looks to me like a design flaw in Boost. The adaptors are not designed=
=20
> to compose, yet the syntax they chose allows well-formed expressions that=
=20
> fail at runtime.
>
It was a perfectly reasonable decision in C++03, where nobody sane would=20
write down the type of a complicated adapter chain, and so the main use=20
case of such chains was as the argument to an algorithm (where template=20
deduction would take care of the type), since any temporaries were sure to=
=20
outlive the function call and then they'd be gone anyway.
The interaction with C++11's auto (including the hidden auto in for-range)=
=20
is what exposed the danger of this design.
=20
> It would have been safer if they=E2=80=99d put the adaptors on the LHS:
>
> boost::adaptors::reversed |
> boost::adaptors::uniqued | vec
>
>
It would also have been completely confusing, given that the syntax was=20
modeled after Unix pipes, which work from left to right.
Sebastian
--=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_248_1644221527.1410301788461
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, August 21, 2014 10:07:21 AM UTC+2, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D=
"word-wrap:break-word">It looks to me like a design flaw in Boost. The adap=
tors are not designed to compose, yet the syntax they chose allows well-for=
med expressions that fail at runtime.</div></blockquote><div><br>It was a p=
erfectly reasonable decision in C++03, where nobody sane would write down t=
he type of a complicated adapter chain, and so the main use case of such ch=
ains was as the argument to an algorithm (where template deduction would ta=
ke care of the type), since any temporaries were sure to outlive the functi=
on call and then they'd be gone anyway.<br><br>The interaction with C++11's=
auto (including the hidden auto in for-range) is what exposed the danger o=
f this design.<br> </div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div style=3D"word-wrap:break-word"> It would have been safer if they=E2=80=
=99d put the adaptors on the LHS:<div><pre><code>boost::adaptors::reversed =
|
boost::adaptors::uniqued | vec</code></pre></div></div></blockquote><div><=
br>It would also have been completely confusing, given that the syntax was =
modeled after Unix pipes, which work from left to right.<br><br>Sebastian<b=
r></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_248_1644221527.1410301788461--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 01 Oct 2014 14:32:09 -0400
Raw View
On 2014-08-16 07:05, Jonathan Coe wrote:
> Sometimes it's desirable to use const methods on a non-const object.
> This can be done with const_cast, but const_cast can equally well be used
> to do potentially unsafe things and is often flagged up in code reviews or
> banned outright by coding standards/pre-commit scripts.
>
> I propose the addition of a simple function:
>
> template <typename T>
> std::as_const(T&& t)
> {
> return const_cast<const T&&>(t);
> }
>
> which can be used to perform the safe const-cast operation.
I'd like to allow using 'const' as a unary operator:
A a; auto&& const_a = const a; // const_a has type 'A const&'
for (auto item : const list) {...}
auto bar = Bar{}; foo(const bar);
// etc.
I seem to recall there are cases where this would make sense where it is
not possible to use a function to the same effect. (But I may be wrong;
for one, your version has more '&'s than I remember using at the time...)
In either case, I'm in favor.
--
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/.
.