Topic: Proposal: A Safe Switch Statement for C++17
Author: inkwizytoryankes@gmail.com
Date: Sun, 17 Nov 2013 05:23:10 -0800 (PST)
Raw View
------=_Part_1539_18154538.1384694590420
Content-Type: text/plain; charset=ISO-8859-1
It would be better add attribute to switch that will reject all error prone
constructs? Main difference will be that this approach could not introduce
new scope for each case but will reject code that access data from
different case. Consider code like that:
int i = 0;
switch(rand()%2)
{
case 0:
int i = 5;
case 1:
i += 5;
}
changing switch to safe switch will silently change meaning of this code
and hide bug.
In my approach this will be simply rejected as invalid.
On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:
>
> I'm working on a proposal following the recent switch statement thread,
> about a new Safe Switch Statement intended for the C++17 timeframe.
>
> Latest draft is here:
>
> https://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md
>
> Feedback appreciated. Also, if anyone is old enough to vet the History
> section for accuracy that would be awesome. :)
>
>
--
---
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_1539_18154538.1384694590420
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It would be better add attribute to switch that will rejec=
t all error prone constructs? Main difference will be that this approach co=
uld not introduce new scope for each case but will reject code that access =
data from different case. Consider code like that:<br><div class=3D"prettyp=
rint" 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"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" c=
lass=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-b=
y-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">switch</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><code cl=
ass=3D"prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">rand</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()%=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">2</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"></span></code><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><span style=3D"color: #008;" class=
=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">0</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: #008;" class=3D"styled-by-prettify">i=
nt</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </spa=
n><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">5</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; i </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">5</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div>changing switch to =
safe switch will silently change meaning of this code and hide bug.<br><br>=
In my approach this will be simply rejected as invalid.<br><br><br>On Sunda=
y, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I'm working on a propo=
sal following the recent switch statement thread, about a new Safe Switch S=
tatement intended for the C++17 timeframe.</div><div><br></div><div>Latest =
draft is here:</div><div><br></div><a href=3D"https://github.com/AndrewToma=
zos/cpp-proposals/blob/master/safe_switch.md" target=3D"_blank">https://git=
hub.com/<wbr>AndrewTomazos/cpp-proposals/<wbr>blob/master/safe_switch.md</a=
><br><div><br></div><div>Feedback appreciated. Also, if anyone is old=
enough to vet the History section for accuracy that would be awesome. :)</=
div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1539_18154538.1384694590420--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Sun, 17 Nov 2013 14:42:37 -0800 (PST)
Raw View
------=_Part_254_8020258.1384728157689
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, November 17, 2013 8:23:10 AM UTC-5, inkwizyt...@gmail.com wrote:
> It would be better add attribute to switch that will reject all error
> prone constructs? Main difference will be that this approach could not
> introduce new scope for each case but will reject code that access data
> from different case. Consider code like that: safe switch will silently
> change meaning of this code and hide bug.
> int i = 0;
> switch(rand()%2)
> {
> case 0:
> int i = 5;
> case 1:
> i += 5;
> }
>
This code will generate an error in Visual C++:.error C2360: initialization
of 'i' is skipped by 'case' label.
In GCC 4.8.1 through compileonline, it generates this error:
main.cpp:12:6: error: jump to case label [-fpermissive]
main.cpp:11:9: error: crosses initialization of 'int i'
So while it does change the meaning, it's hardly a silent change since it
doesn't compile now.
--
---
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_254_8020258.1384728157689
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Sunday, November 17, 2=
013 8:23:10 AM UTC-5, inkwizyt...@gmail.com wrote:</span><br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It would be better add attr=
ibute to switch that will reject all error prone constructs? Main differenc=
e will be that this approach could not introduce new scope for each case bu=
t will reject code that access data from different case. Consider code like=
that: safe switch will silently change meaning of this code and hide=
bug.<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><code=
><div><span style=3D"color:#008">int</span><span style=3D"color:#000"> i </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#066">0</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#008">switch</span>=
<span style=3D"color:#660">(</span><code><span style=3D"color:#000">rand</s=
pan><span style=3D"color:#660">()%</span><span style=3D"color:#066">2</span=
><span style=3D"color:#660"></span></code><span style=3D"color:#660">)</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#008">case</span=
><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span><spa=
n style=3D"color:#660">:</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#008">int</span><span style=3D"color:#000"> i =
</span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#066">5</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br></span><span style=3D"color:#008">case</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#066">1</span><span=
style=3D"color:#660">:</span><span style=3D"color:#000"><br> =
i </span><span style=3D"color:#660">+=3D</span><span style=3D"color:#000"> =
</span><span style=3D"color:#066">5</span><span style=3D"color:#660">;</spa=
n><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</span>=
</div></code></div></div></blockquote><div><br></div><div><span style=3D"fo=
nt-size: 13px;">This code will generate an error in Visual C++:.</span>erro=
r C2360: initialization of 'i' is skipped by 'case' label. <br></div>=
<div><br></div><div>In GCC 4.8.1 through compileonline, it generates this e=
rror:</div><div><br></div><div><span style=3D"color: rgb(0, 0, 0); font-fam=
ily: 'Times New Roman'; font-size: medium;">main.cpp:12:6: error: jump to c=
ase label [-fpermissive]</span><br style=3D"color: rgb(0, 0, 0); font-famil=
y: 'Times New Roman'; font-size: medium;"><span style=3D"color: rgb(0, 0, 0=
); font-family: 'Times New Roman'; font-size: medium;">main.cpp:11:9: error=
: crosses initialization of 'int i'</span><br style=3D"color: rgb(0, 0, 0);=
font-family: 'Times New Roman'; font-size: medium;"><br></div><div>So whil=
e it does change the meaning, it's hardly a silent change since it doesn't =
compile now.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_254_8020258.1384728157689--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Mon, 18 Nov 2013 14:21:36 +0200
Raw View
--047d7b5d668ee169cf04eb7296c1
Content-Type: text/plain; charset=ISO-8859-1
A minor comment. Since your purpose is to make the switch statement avoid
the implicit behaviour of the current switch statement, why
*safe_switch*(which adds a keyword) and not *explicit
switch? *It would be using an already known keyword and the meaning
conveyed is pretty much straightforward and unambiguous.
On Sun, Nov 17, 2013 at 11:15 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> I'm working on a proposal following the recent switch statement thread,
> about a new Safe Switch Statement intended for the C++17 timeframe.
>
> Latest draft is here:
>
> https://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md
>
> Feedback appreciated. Also, if anyone is old enough to vet the History
> section for accuracy that would be awesome. :)
>
> --
>
> ---
> 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/.
--047d7b5d668ee169cf04eb7296c1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A minor comment. Since your purpose is to make the switch =
statement avoid the implicit behaviour of the current switch statement, why=
<b>safe_switch</b> (which adds a keyword) and not <b>explicit switch? </b>=
It would be using an already known keyword and the meaning conveyed is pret=
ty much straightforward and unambiguous.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, Nov 1=
7, 2013 at 11:15 AM, Andrew Tomazos <span dir=3D"ltr"><<a href=3D"mailto=
:andrewtomazos@gmail.com" target=3D"_blank">andrewtomazos@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"><div>I'm working on a p=
roposal following the recent switch statement thread, about a new Safe Swit=
ch Statement intended for the C++17 timeframe.</div>
<div><br></div><div>Latest draft is here:</div><div><br></div><a href=3D"ht=
tps://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md" ta=
rget=3D"_blank">https://github.com/AndrewTomazos/cpp-proposals/blob/master/=
safe_switch.md</a><br>
<div><br></div><div>Feedback appreciated. =A0Also, if anyone is old enough =
to vet the History section for accuracy that would be awesome. :)</div><spa=
n class=3D"HOEnZb"><font color=3D"#888888"><div><br></div></font></span></d=
iv>
<span class=3D"HOEnZb"><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
</font></span></blockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5d668ee169cf04eb7296c1--
.
Author: inkwizytoryankes@gmail.com
Date: Mon, 18 Nov 2013 10:50:52 -0800 (PST)
Raw View
------=_Part_2375_5598952.1384800652963
Content-Type: text/plain; charset=ISO-8859-1
Right, I modify example form Andrew proposition without compiling it first.
At least that example can be removed as "RESOLVED" :)
I think that if `secure_switch` and `switch` work in different way then
that become new sources of confusion for beginning users.
`[[secure]]` attribute will be easer to understand because you can
delete/ignore it and switch work exactly same. only adding it will require
some work.
On Sunday, November 17, 2013 11:42:37 PM UTC+1, Greg Marr wrote:
>
> On Sunday, November 17, 2013 8:23:10 AM UTC-5, inkwizyt...@gmail.comwrote:
>
>> It would be better add attribute to switch that will reject all error
>> prone constructs? Main difference will be that this approach could not
>> introduce new scope for each case but will reject code that access data
>> from different case. Consider code like that: safe switch will silently
>> change meaning of this code and hide bug.
>> int i = 0;
>> switch(rand()%2)
>> {
>> case 0:
>> int i = 5;
>> case 1:
>> i += 5;
>> }
>>
>
> This code will generate an error in Visual C++:.error C2360:
> initialization of 'i' is skipped by 'case' label.
>
> In GCC 4.8.1 through compileonline, it generates this error:
>
> main.cpp:12:6: error: jump to case label [-fpermissive]
> main.cpp:11:9: error: crosses initialization of 'int i'
>
> So while it does change the meaning, it's hardly a silent change since it
> doesn't compile now.
>
>
On Sunday, November 17, 2013 11:42:37 PM UTC+1, Greg Marr wrote:
>
> On Sunday, November 17, 2013 8:23:10 AM UTC-5, inkwizyt...@gmail.comwrote:
>
>> It would be better add attribute to switch that will reject all error
>> prone constructs? Main difference will be that this approach could not
>> introduce new scope for each case but will reject code that access data
>> from different case. Consider code like that: safe switch will silently
>> change meaning of this code and hide bug.
>> int i = 0;
>> switch(rand()%2)
>> {
>> case 0:
>> int i = 5;
>> case 1:
>> i += 5;
>> }
>>
>
> This code will generate an error in Visual C++:.error C2360:
> initialization of 'i' is skipped by 'case' label.
>
> In GCC 4.8.1 through compileonline, it generates this error:
>
> main.cpp:12:6: error: jump to case label [-fpermissive]
> main.cpp:11:9: error: crosses initialization of 'int i'
>
> So while it does change the meaning, it's hardly a silent change since it
> doesn't compile now.
>
>
--
---
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_2375_5598952.1384800652963
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Right, I modify example form Andrew proposition without co=
mpiling it first. At least that example can be removed as "RESOLVED" :)<br>=
I think that if `secure_switch` and `switch` work in different way then tha=
t become new sources of confusion for beginning users.<br>`[[secure]]` attr=
ibute will be easer to understand because you can delete/ignore it and swit=
ch work exactly same. only adding it will require some work.<br><br>On Sund=
ay, November 17, 2013 11:42:37 PM UTC+1, Greg Marr wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><span style=3D"font-size:13px"=
>On Sunday, November 17, 2013 8:23:10 AM UTC-5, <a>inkwizyt...@gmail.com</a=
> wrote:</span><br><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
>It would be better add attribute to switch that will reject all error pron=
e constructs? Main difference will be that this approach could not introduc=
e new scope for each case but will reject code that access data from differ=
ent case. Consider code like that: safe switch will silently change m=
eaning of this code and hide bug.<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"><code><div><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> i </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">switch</span><span style=3D"color:#660">(</span><code><span=
style=3D"color:#000">rand</span><span style=3D"color:#660">()%</span><span=
style=3D"color:#066">2</span><span style=3D"color:#660"></span></code><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#008">case</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#066">0</span><span style=3D"color:#660">:</span><span style=3D"=
color:#000"><br> </span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> i </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#066">5</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#008">case</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"><br> i </span><span style=3D"color:#660">+=3D</span=
><span style=3D"color:#000"> </span><span style=3D"color:#066">5</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">}</span></div></code></div></div></blockquote><div><br=
></div><div><span style=3D"font-size:13px">This code will generate an error=
in Visual C++:.</span>error C2360: initialization of 'i' is skipped by 'ca=
se' label. <br></div><div><br></div><div>In GCC 4.8.1 through compile=
online, it generates this error:</div><div><br></div><div><span style=3D"co=
lor:rgb(0,0,0);font-family:'Times New Roman';font-size:medium">main.cpp:12:=
6: error: jump to case label [-fpermissive]</span><br style=3D"color:rgb(0,=
0,0);font-family:'Times New Roman';font-size:medium"><span style=3D"color:r=
gb(0,0,0);font-family:'Times New Roman';font-size:medium">main.cpp:11:9: er=
ror: crosses initialization of 'int i'</span><br style=3D"color:rgb(0,0,0);=
font-family:'Times New Roman';font-size:medium"><br></div><div>So while it =
does change the meaning, it's hardly a silent change since it doesn't compi=
le now.</div><div><br></div></div></blockquote><br>On Sunday, November 17, =
2013 11:42:37 PM UTC+1, Greg Marr wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr"><span style=3D"font-size:13px">On Sunday, Novemb=
er 17, 2013 8:23:10 AM UTC-5, <a>inkwizyt...@gmail.com</a> wrote:</span><br=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It would be bette=
r add attribute to switch that will reject all error prone constructs? Main=
difference will be that this approach could not introduce new scope for ea=
ch case but will reject code that access data from different case. Consider=
code like that: safe switch will silently change meaning of this cod=
e and hide bug.<br><div style=3D"background-color:rgb(250,250,250);border-c=
olor:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-w=
ord"><code><div><span style=3D"color:#008">int</span><span style=3D"color:#=
000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#066">0</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">swi=
tch</span><span style=3D"color:#660">(</span><code><span style=3D"color:#00=
0">rand</span><span style=3D"color:#660">()%</span><span style=3D"color:#06=
6">2</span><span style=3D"color:#660"></span></code><span style=3D"color:#6=
60">)</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">{</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">=
case</span><span style=3D"color:#000"> </span><span style=3D"color:#066">0<=
/span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br>&nb=
sp; </span><span style=3D"color:#008">int</span><span style=3D"color=
:#000"> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:=
#000"> </span><span style=3D"color:#066">5</span><span style=3D"color:#660"=
>;</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">c=
ase</span><span style=3D"color:#000"> </span><span style=3D"color:#066">1</=
span><span style=3D"color:#660">:</span><span style=3D"color:#000"><br>&nbs=
p; i </span><span style=3D"color:#660">+=3D</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#066">5</span><span style=3D"color:#6=
60">;</span><span style=3D"color:#000"><br></span><span style=3D"color:#660=
">}</span></div></code></div></div></blockquote><div><br></div><div><span s=
tyle=3D"font-size:13px">This code will generate an error in Visual C++:.</s=
pan>error C2360: initialization of 'i' is skipped by 'case' label. <b=
r></div><div><br></div><div>In GCC 4.8.1 through compileonline, it generate=
s this error:</div><div><br></div><div><span style=3D"color:rgb(0,0,0);font=
-family:'Times New Roman';font-size:medium">main.cpp:12:6: error: jump to c=
ase label [-fpermissive]</span><br style=3D"color:rgb(0,0,0);font-family:'T=
imes New Roman';font-size:medium"><span style=3D"color:rgb(0,0,0);font-fami=
ly:'Times New Roman';font-size:medium">main.cpp:11:9: error: crosses initia=
lization of 'int i'</span><br style=3D"color:rgb(0,0,0);font-family:'Times =
New Roman';font-size:medium"><br></div><div>So while it does change the mea=
ning, it's hardly a silent change since it doesn't compile now.</div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2375_5598952.1384800652963--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 18 Nov 2013 12:21:32 -0800 (PST)
Raw View
------=_Part_443_25792082.1384806092850
Content-Type: text/plain; charset=ISO-8859-1
Whether a safe switch is introduced by an attribute such as `[[safe]]
switch` or a combination of keywords such as `explicit switch` or a new
keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
have plenty of time to think about that. At time of writing I am leaning
towards `explicit switch` as Greg Marr suggests.
As for your example, we should notice first of all this would only come up
if a local name in the outermost scope of a case statement hides a name
from an outer scope, and that name is used by a different case statement.
At the moment in an existing switch this is detected as a jump past
initialization error by tools, under a safe switch the name would bind to
the outer hidden name.
One option would be for safe switch case statements to not introduce a new
scope as you suggest, and ask programmers to manually wrap the case
statement in a compound statement as they do now in reaction when the error
is raised.
I've thought about this, and I think a better solution would be to consider
such a situation ill-formed. That is, we have safe switch case statements
each introduce a new scope as proposed, but add a rule that says something
like:
If a name introduced into the outermost declarative region of a case
statement hides a name from an outer scope, and unqualified name lookup
from within a following case statement of the same switch finds the hidden
name, the program is ill-formed. [Note: In such cases the case statement
introducing the name can be enclosed in a compound statement, or the
introduced name can be changed to no longer hide the outer one.]
In such a way, such a situation would be detected. We should keep in mind
that this is a corner case, and the way this corner case is handled the
same as it is today (with a diagnostic). For the remaining majority of
cases, we can fix the annoying need to wrap each case statement in a
compound statement to declare a local variable (by introducing a per case
statement scope as proposed):
explicit switch (foo)
{
case a:
case b:
T x = y;
x.f();
if (x > z)
break;
else if (x < w)
goto case c;
else
throw qux;
// no fallthrough - statically checked
case c:
U x = w; // ok, different scope
while (x > z)
x++;
break;
default:
g();
}
On Sunday, November 17, 2013 2:23:10 PM UTC+1, inkwizyt...@gmail.com wrote:
>
> It would be better add attribute to switch that will reject all error
> prone constructs? Main difference will be that this approach could not
> introduce new scope for each case but will reject code that access data
> from different case. Consider code like that:
> int i = 0;
> switch(rand()%2)
> {
> case 0:
> int i = 5;
> case 1:
> i += 5;
> }
> changing switch to safe switch will silently change meaning of this code
> and hide bug.
>
> In my approach this will be simply rejected as invalid.
>
>
> On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:
>>
>> I'm working on a proposal following the recent switch statement thread,
>> about a new Safe Switch Statement intended for the C++17 timeframe.
>>
>> Latest draft is here:
>>
>> https://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md
>>
>> Feedback appreciated. Also, if anyone is old enough to vet the History
>> section for accuracy that would be awesome. :)
>>
>>
--
---
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_443_25792082.1384806092850
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Whether a safe switch is introduced by an attribute such a=
s `[[safe]] switch` or a combination of keywords such as `explicit switch` =
or a new keyword such as `safe_switch` is a bit of a bikeshed at this point=
, and we have plenty of time to think about that. At time of writing =
I am leaning towards `explicit switch` as Greg Marr suggests.<div><br></div=
><div>As for your example, we should notice first of all this would only co=
me up if a local name in the outermost scope of a case statement hides a na=
me from an outer scope, and that name is used by a different case statement=
.. At the moment in an existing switch this is detected as a jump past=
initialization error by tools, under a safe switch the name would bind to =
the outer hidden name.</div><div><br></div><div>One option would be for saf=
e switch case statements to not introduce a new scope as you suggest, and a=
sk programmers to manually wrap the case statement in a compound statement =
as they do now in reaction when the error is raised.</div><div><br></div><d=
iv>I've thought about this, and I think a better solution would be to consi=
der such a situation ill-formed. That is, we have safe switch case st=
atements each introduce a new scope as proposed, but add a rule that says s=
omething like:</div><div><br></div><div>If a name introduced into the outer=
most declarative region of a case statement hides a name from an outer scop=
e, and unqualified name lookup from within a following case statement of th=
e same switch finds the hidden name, the program is ill-formed. [Note: In s=
uch cases the case statement introducing the name can be enclosed in a comp=
ound statement, or the introduced name can be changed to no longer hide the=
outer one.]</div><div><br></div><div>In such a way, such a situation would=
be detected. We should keep in mind that this is a corner case, and =
the way this corner case is handled the same as it is today (with a diagnos=
tic). For the remaining majority of cases, we can fix the annoying ne=
ed to wrap each case statement in a compound statement to declare a local v=
ariable (by introducing a per case statement scope as proposed):</div><div>=
<br></div><div><font face=3D"courier new, monospace"> explicit=
switch (foo)</font></div><div><font face=3D"courier new, monospace"> =
{</font></div><div><font face=3D"courier new, monospace"> &nb=
sp; case a:</font></div><div><font face=3D"courier new, monospace"> &=
nbsp; case b:</font></div><div><font face=3D"courier new, monospace"> =
T x =3D y;</font></div><div><font face=3D"courier new=
, monospace"> x.f();</font></div><div><font face=
=3D"courier new, monospace"> if (x > z)</font=
></div><div><font face=3D"courier new, monospace"> &nbs=
p; break;</font></div><div><font face=3D"courier new, monospac=
e"> else if (x < w)</font></div><div><font fa=
ce=3D"courier new, monospace"> goto=
case c;</font></div><div><font face=3D"courier new, monospace"> &nbs=
p; else</font></div><div><font face=3D"courier new, monospace=
"> throw qux;</font></div><div><fon=
t face=3D"courier new, monospace"><br></font></div><div><font face=3D"couri=
er new, monospace"> // no fallthrough - statical=
ly checked</font></div><div><font face=3D"courier new, monospace"><br></fon=
t></div><div><font face=3D"courier new, monospace"> case c:</f=
ont></div><div><font face=3D"courier new, monospace"> &=
nbsp; U x =3D w; // ok, different scope</font></div><div><font face=3D"cour=
ier new, monospace"> while (x > z)</font></di=
v><div><font face=3D"courier new, monospace"> &n=
bsp; x++;</font></div><div><font face=3D"courier new, monospace">&nbs=
p; break;</font></div><div><font face=3D"courier new, =
monospace"><br></font></div><div><font face=3D"courier new, monospace">&nbs=
p; default:</font></div><div><font face=3D"courier new, monospace">&=
nbsp; g();</font></div><div><font face=3D"courier new,=
monospace"> }</font><br></div><div><br></div><div>On Sunday, =
November 17, 2013 2:23:10 PM UTC+1, inkwizyt...@gmail.com wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">It would be better add a=
ttribute to switch that will reject all error prone constructs? Main differ=
ence will be that this approach could not introduce new scope for each case=
but will reject code that access data from different case. Consider code l=
ike that:<br><div style=3D"background-color:rgb(250,250,250);border-color:r=
gb(187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><=
code><div><span style=3D"color:#008">int</span><span style=3D"color:#000"> =
i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#066">0</span><span style=3D"color:#660">;</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#008">switch</s=
pan><span style=3D"color:#660">(</span><code><span style=3D"color:#000">ran=
d</span><span style=3D"color:#660">()%</span><span style=3D"color:#066">2</=
span><span style=3D"color:#660"></span></code><span style=3D"color:#660">)<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#660">{</s=
pan><span style=3D"color:#000"><br></span><span style=3D"color:#008">case</=
span><span style=3D"color:#000"> </span><span style=3D"color:#066">0</span>=
<span style=3D"color:#660">:</span><span style=3D"color:#000"><br> &n=
bsp; </span><span style=3D"color:#008">int</span><span style=3D"color:#000"=
> i </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000">=
</span><span style=3D"color:#066">5</span><span style=3D"color:#660">;</sp=
an><span style=3D"color:#000"><br></span><span style=3D"color:#008">case</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#066">1</span><=
span style=3D"color:#660">:</span><span style=3D"color:#000"><br> &nb=
sp; i </span><span style=3D"color:#660">+=3D</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#066">5</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}</s=
pan><span style=3D"color:#000"><br></span></div></code></div>changing switc=
h to safe switch will silently change meaning of this code and hide bug.<br=
><br>In my approach this will be simply rejected as invalid.<br><br><br>On =
Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:<blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I'm working on a propo=
sal following the recent switch statement thread, about a new Safe Switch S=
tatement intended for the C++17 timeframe.</div><div><br></div><div>Latest =
draft is here:</div><div><br></div><a href=3D"https://github.com/AndrewToma=
zos/cpp-proposals/blob/master/safe_switch.md" target=3D"_blank">https://git=
hub.com/<wbr>AndrewTomazos/cpp-proposals/<wbr>blob/master/safe_switch.md</a=
><br><div><br></div><div>Feedback appreciated. Also, if anyone is old=
enough to vet the History section for accuracy that would be awesome. :)</=
div><div><br></div></div></blockquote></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_443_25792082.1384806092850--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 18 Nov 2013 12:25:03 -0800
Raw View
--001a1134850034e77b04eb795a68
Content-Type: text/plain; charset=ISO-8859-1
Perhaps we should consider just recommending programmers use an if / else
if ladder instead...
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Nov 18, 2013 at 12:21 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> Whether a safe switch is introduced by an attribute such as `[[safe]]
> switch` or a combination of keywords such as `explicit switch` or a new
> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
> have plenty of time to think about that. At time of writing I am leaning
> towards `explicit switch` as Greg Marr suggests.
>
> As for your example, we should notice first of all this would only come up
> if a local name in the outermost scope of a case statement hides a name
> from an outer scope, and that name is used by a different case statement.
> At the moment in an existing switch this is detected as a jump past
> initialization error by tools, under a safe switch the name would bind to
> the outer hidden name.
>
> One option would be for safe switch case statements to not introduce a new
> scope as you suggest, and ask programmers to manually wrap the case
> statement in a compound statement as they do now in reaction when the error
> is raised.
>
> I've thought about this, and I think a better solution would be to
> consider such a situation ill-formed. That is, we have safe switch case
> statements each introduce a new scope as proposed, but add a rule that says
> something like:
>
> If a name introduced into the outermost declarative region of a case
> statement hides a name from an outer scope, and unqualified name lookup
> from within a following case statement of the same switch finds the hidden
> name, the program is ill-formed. [Note: In such cases the case statement
> introducing the name can be enclosed in a compound statement, or the
> introduced name can be changed to no longer hide the outer one.]
>
> In such a way, such a situation would be detected. We should keep in mind
> that this is a corner case, and the way this corner case is handled the
> same as it is today (with a diagnostic). For the remaining majority of
> cases, we can fix the annoying need to wrap each case statement in a
> compound statement to declare a local variable (by introducing a per case
> statement scope as proposed):
>
> explicit switch (foo)
> {
> case a:
> case b:
> T x = y;
> x.f();
> if (x > z)
> break;
> else if (x < w)
> goto case c;
> else
> throw qux;
>
> // no fallthrough - statically checked
>
> case c:
> U x = w; // ok, different scope
> while (x > z)
> x++;
> break;
>
> default:
> g();
> }
>
> On Sunday, November 17, 2013 2:23:10 PM UTC+1, inkwizyt...@gmail.comwrote:
>>
>> It would be better add attribute to switch that will reject all error
>> prone constructs? Main difference will be that this approach could not
>> introduce new scope for each case but will reject code that access data
>> from different case. Consider code like that:
>> int i = 0;
>> switch(rand()%2)
>> {
>> case 0:
>> int i = 5;
>> case 1:
>> i += 5;
>> }
>> changing switch to safe switch will silently change meaning of this code
>> and hide bug.
>>
>> In my approach this will be simply rejected as invalid.
>>
>>
>> On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:
>>>
>>> I'm working on a proposal following the recent switch statement thread,
>>> about a new Safe Switch Statement intended for the C++17 timeframe.
>>>
>>> Latest draft is here:
>>>
>>> https://github.com/AndrewTomazos/cpp-proposals/
>>> blob/master/safe_switch.md
>>>
>>> Feedback appreciated. Also, if anyone is old enough to vet the History
>>> section for accuracy that would be awesome. :)
>>>
>>> --
>
> ---
> 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/.
--001a1134850034e77b04eb795a68
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Perhaps we should consider just recommending programmers u=
se an if / else if ladder instead...</div><div class=3D"gmail_extra"><br cl=
ear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=
=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github.com=
/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 12:21 PM, Andrew=
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" t=
arget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr">Whether a safe switch is introduced by an attribute such a=
s `[[safe]] switch` or a combination of keywords such as `explicit switch` =
or a new keyword such as `safe_switch` is a bit of a bikeshed at this point=
, and we have plenty of time to think about that. =A0At time of writing I a=
m leaning towards `explicit switch` as Greg Marr suggests.<div>
<br></div><div>As for your example, we should notice first of all this woul=
d only come up if a local name in the outermost scope of a case statement h=
ides a name from an outer scope, and that name is used by a different case =
statement. =A0At the moment in an existing switch this is detected as a jum=
p past initialization error by tools, under a safe switch the name would bi=
nd to the outer hidden name.</div>
<div><br></div><div>One option would be for safe switch case statements to =
not introduce a new scope as you suggest, and ask programmers to manually w=
rap the case statement in a compound statement as they do now in reaction w=
hen the error is raised.</div>
<div><br></div><div>I've thought about this, and I think a better solut=
ion would be to consider such a situation ill-formed. =A0That is, we have s=
afe switch case statements each introduce a new scope as proposed, but add =
a rule that says something like:</div>
<div><br></div><div>If a name introduced into the outermost declarative reg=
ion of a case statement hides a name from an outer scope, and unqualified n=
ame lookup from within a following case statement of the same switch finds =
the hidden name, the program is ill-formed. [Note: In such cases the case s=
tatement introducing the name can be enclosed in a compound statement, or t=
he introduced name can be changed to no longer hide the outer one.]</div>
<div><br></div><div>In such a way, such a situation would be detected. =A0W=
e should keep in mind that this is a corner case, and the way this corner c=
ase is handled the same as it is today (with a diagnostic). =A0For the rema=
ining majority of cases, we can fix the annoying need to wrap each case sta=
tement in a compound statement to declare a local variable (by introducing =
a per case statement scope as proposed):</div>
<div><br></div><div><font face=3D"courier new, monospace">=A0 =A0 explicit =
switch (foo)</font></div><div><font face=3D"courier new, monospace">=A0 =A0=
{</font></div><div><font face=3D"courier new, monospace">=A0 =A0 case a:</=
font></div><div>
<font face=3D"courier new, monospace">=A0 =A0 case b:</font></div><div><fon=
t face=3D"courier new, monospace">=A0 =A0 =A0 =A0 T x =3D y;</font></div><d=
iv><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 x.f();</font></div=
><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 if (x > z)</=
font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0break;</f=
ont></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 else i=
f (x < w)</font></div><div><font face=3D"courier new, monospace">=A0 =A0=
=A0 =A0 =A0 =A0goto case c;</font></div>
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 else</font></div=
><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0throw qu=
x;</font></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 // no fallthroug=
h - statically checked</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">=A0 =A0 case c:</font></div><div><font face=3D"=
courier new, monospace">=A0 =A0 =A0 =A0 U x =3D w; // ok, different scope</=
font></div><div>
<font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 while (x > z)</fon=
t></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =A0 =A0x=
++;</font></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 =
break;</font></div><div><font face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">=A0 =A0 default:</f=
ont></div><div><font face=3D"courier new, monospace">=A0 =A0 =A0 =A0 g();</=
font></div><div><font face=3D"courier new, monospace">=A0 =A0 }</font><br><=
/div><div><br></div>
<div>On Sunday, November 17, 2013 2:23:10 PM UTC+1, <a href=3D"mailto:inkwi=
zyt...@gmail.com" target=3D"_blank">inkwizyt...@gmail.com</a> wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1=
ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-sty=
le:solid">
<div dir=3D"ltr">It would be better add attribute to switch that will rejec=
t all error prone constructs? Main difference will be that this approach co=
uld not introduce new scope for each case but will reject code that access =
data from different case. Consider code like that:<br>
<div style=3D"border:1px solid rgb(187,187,187);background-color:rgb(250,25=
0,250)"><code><div><span style=3D"color:rgb(0,0,136)">int</span><span> i </=
span><span style=3D"color:rgb(102,102,0)">=3D</span><span> </span><span sty=
le=3D"color:rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">;<=
/span><span><br>
</span><span style=3D"color:rgb(0,0,136)">switch</span><span style=3D"color=
:rgb(102,102,0)">(</span><code><span>rand</span><span style=3D"color:rgb(10=
2,102,0)">()%</span><span style=3D"color:rgb(0,102,102)">2</span><span styl=
e=3D"color:rgb(102,102,0)"></span></code><span style=3D"color:rgb(102,102,0=
)">)</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">{</span><span><br></span><span =
style=3D"color:rgb(0,0,136)">case</span><span> </span><span style=3D"color:=
rgb(0,102,102)">0</span><span style=3D"color:rgb(102,102,0)">:</span><span>=
<br>
=A0 =A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span> i </span=
><span style=3D"color:rgb(102,102,0)">=3D</span><span> </span><span style=
=3D"color:rgb(0,102,102)">5</span><span style=3D"color:rgb(102,102,0)">;</s=
pan><span><br>
</span><span style=3D"color:rgb(0,0,136)">case</span><span> </span><span st=
yle=3D"color:rgb(0,102,102)">1</span><span style=3D"color:rgb(102,102,0)">:=
</span><span><br>=A0 =A0 i </span><span style=3D"color:rgb(102,102,0)">+=3D=
</span><span> </span><span style=3D"color:rgb(0,102,102)">5</span><span sty=
le=3D"color:rgb(102,102,0)">;</span><span><br>
</span><span style=3D"color:rgb(102,102,0)">}</span><span><br></span></div>=
</code></div>changing switch to safe switch will silently change meaning of=
this code and hide bug.<br><br>In my approach this will be simply rejected=
as invalid.<br>
<br><br>On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;paddi=
ng-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border=
-left-style:solid">
<div dir=3D"ltr"><div>I'm working on a proposal following the recent sw=
itch statement thread, about a new Safe Switch Statement intended for the C=
++17 timeframe.</div><div><br></div><div>Latest draft is here:</div><div>
<br></div><a href=3D"https://github.com/AndrewTomazos/cpp-proposals/blob/ma=
ster/safe_switch.md" target=3D"_blank">https://github.com/<u></u>AndrewToma=
zos/cpp-proposals/<u></u>blob/master/safe_switch.md</a><br><div><br></div>
<div>
Feedback appreciated. =A0Also, if anyone is old enough to vet the History s=
ection for accuracy that would be awesome. :)</div><div><br></div></div></b=
lockquote></div></blockquote></div></div><span class=3D"HOEnZb"><font color=
=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
</font></span></blockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1134850034e77b04eb795a68--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 18 Nov 2013 12:26:38 -0800 (PST)
Raw View
------=_Part_1994_24147466.1384806398194
Content-Type: text/plain; charset=ISO-8859-1
....as George Makrydakis suggests, not Greg Marr. My apologies.
On Monday, November 18, 2013 9:21:32 PM UTC+1, Andrew Tomazos wrote:
>
> Whether a safe switch is introduced by an attribute such as `[[safe]]
> switch` or a combination of keywords such as `explicit switch` or a new
> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
> have plenty of time to think about that. At time of writing I am leaning
> towards `explicit switch` as Greg Marr suggests.
>
> As for your example, we should notice first of all this would only come up
> if a local name in the outermost scope of a case statement hides a name
> from an outer scope, and that name is used by a different case statement.
> At the moment in an existing switch this is detected as a jump past
> initialization error by tools, under a safe switch the name would bind to
> the outer hidden name.
>
> One option would be for safe switch case statements to not introduce a new
> scope as you suggest, and ask programmers to manually wrap the case
> statement in a compound statement as they do now in reaction when the error
> is raised.
>
> I've thought about this, and I think a better solution would be to
> consider such a situation ill-formed. That is, we have safe switch case
> statements each introduce a new scope as proposed, but add a rule that says
> something like:
>
> If a name introduced into the outermost declarative region of a case
> statement hides a name from an outer scope, and unqualified name lookup
> from within a following case statement of the same switch finds the hidden
> name, the program is ill-formed. [Note: In such cases the case statement
> introducing the name can be enclosed in a compound statement, or the
> introduced name can be changed to no longer hide the outer one.]
>
> In such a way, such a situation would be detected. We should keep in mind
> that this is a corner case, and the way this corner case is handled the
> same as it is today (with a diagnostic). For the remaining majority of
> cases, we can fix the annoying need to wrap each case statement in a
> compound statement to declare a local variable (by introducing a per case
> statement scope as proposed):
>
> explicit switch (foo)
> {
> case a:
> case b:
> T x = y;
> x.f();
> if (x > z)
> break;
> else if (x < w)
> goto case c;
> else
> throw qux;
>
> // no fallthrough - statically checked
>
> case c:
> U x = w; // ok, different scope
> while (x > z)
> x++;
> break;
>
> default:
> g();
> }
>
> On Sunday, November 17, 2013 2:23:10 PM UTC+1, inkwizyt...@gmail.comwrote:
>>
>> It would be better add attribute to switch that will reject all error
>> prone constructs? Main difference will be that this approach could not
>> introduce new scope for each case but will reject code that access data
>> from different case. Consider code like that:
>> int i = 0;
>> switch(rand()%2)
>> {
>> case 0:
>> int i = 5;
>> case 1:
>> i += 5;
>> }
>> changing switch to safe switch will silently change meaning of this code
>> and hide bug.
>>
>> In my approach this will be simply rejected as invalid.
>>
>>
>> On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andrew Tomazos wrote:
>>>
>>> I'm working on a proposal following the recent switch statement thread,
>>> about a new Safe Switch Statement intended for the C++17 timeframe.
>>>
>>> Latest draft is here:
>>>
>>> https://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md
>>>
>>> Feedback appreciated. Also, if anyone is old enough to vet the History
>>> section for accuracy that would be awesome. :)
>>>
>>>
--
---
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_1994_24147466.1384806398194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font face=3D"arial, sans-serif">...as George Makrydakis s=
uggests, not Greg Marr. My apologies.</font><div><br>On Monday, Novem=
ber 18, 2013 9:21:32 PM UTC+1, Andrew Tomazos wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr">Whether a safe switch is introduced =
by an attribute such as `[[safe]] switch` or a combination of keywords such=
as `explicit switch` or a new keyword such as `safe_switch` is a bit of a =
bikeshed at this point, and we have plenty of time to think about that. &nb=
sp;At time of writing I am leaning towards `explicit switch` as Greg Marr s=
uggests.<div><br></div><div>As for your example, we should notice first of =
all this would only come up if a local name in the outermost scope of a cas=
e statement hides a name from an outer scope, and that name is used by a di=
fferent case statement. At the moment in an existing switch this is d=
etected as a jump past initialization error by tools, under a safe switch t=
he name would bind to the outer hidden name.</div><div><br></div><div>One o=
ption would be for safe switch case statements to not introduce a new scope=
as you suggest, and ask programmers to manually wrap the case statement in=
a compound statement as they do now in reaction when the error is raised.<=
/div><div><br></div><div>I've thought about this, and I think a better solu=
tion would be to consider such a situation ill-formed. That is, we ha=
ve safe switch case statements each introduce a new scope as proposed, but =
add a rule that says something like:</div><div><br></div><div>If a name int=
roduced into the outermost declarative region of a case statement hides a n=
ame from an outer scope, and unqualified name lookup from within a followin=
g case statement of the same switch finds the hidden name, the program is i=
ll-formed. [Note: In such cases the case statement introducing the name can=
be enclosed in a compound statement, or the introduced name can be changed=
to no longer hide the outer one.]</div><div><br></div><div>In such a way, =
such a situation would be detected. We should keep in mind that this =
is a corner case, and the way this corner case is handled the same as it is=
today (with a diagnostic). For the remaining majority of cases, we c=
an fix the annoying need to wrap each case statement in a compound statemen=
t to declare a local variable (by introducing a per case statement scope as=
proposed):</div><div><br></div><div><font face=3D"courier new, monospace">=
explicit switch (foo)</font></div><div><font face=3D"courier =
new, monospace"> {</font></div><div><font face=3D"courier new,=
monospace"> case a:</font></div><div><font face=3D"courier ne=
w, monospace"> case b:</font></div><div><font face=3D"courier =
new, monospace"> T x =3D y;</font></div><div><fo=
nt face=3D"courier new, monospace"> x.f();</font=
></div><div><font face=3D"courier new, monospace"> &nbs=
p; if (x > z)</font></div><div><font face=3D"courier new, monospace">&nb=
sp; break;</font></div><div><font face=3D=
"courier new, monospace"> else if (x < w)</fo=
nt></div><div><font face=3D"courier new, monospace"> &n=
bsp; goto case c;</font></div><div><font face=3D"courier new, =
monospace"> else</font></div><div><font face=3D"=
courier new, monospace"> throw qux;=
</font></div><div><font face=3D"courier new, monospace"><br></font></div><d=
iv><font face=3D"courier new, monospace"> // no =
fallthrough - statically checked</font></div><div><font face=3D"courier new=
, monospace"><br></font></div><div><font face=3D"courier new, monospace">&n=
bsp; case c:</font></div><div><font face=3D"courier new, monospace">=
U x =3D w; // ok, different scope</font></div><=
div><font face=3D"courier new, monospace"> while=
(x > z)</font></div><div><font face=3D"courier new, monospace"> &=
nbsp; x++;</font></div><div><font face=3D"courie=
r new, monospace"> break;</font></div><div><font=
face=3D"courier new, monospace"><br></font></div><div><font face=3D"courie=
r new, monospace"> default:</font></div><div><font face=3D"cou=
rier new, monospace"> g();</font></div><div><fon=
t face=3D"courier new, monospace"> }</font><br></div><div><br>=
</div><div>On Sunday, November 17, 2013 2:23:10 PM UTC+1, <a>inkwizyt...@gm=
ail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
It would be better add attribute to switch that will reject all error prone=
constructs? Main difference will be that this approach could not introduce=
new scope for each case but will reject code that access data from differe=
nt case. Consider code like that:<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"><code><div><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> i </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">0</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">switch</span><span style=3D"color:#660">(</span><code><span=
style=3D"color:#000">rand</span><span style=3D"color:#660">()%</span><span=
style=3D"color:#066">2</span><span style=3D"color:#660"></span></code><spa=
n style=3D"color:#660">)</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">{</span><span style=3D"color:#000"><br></span><span st=
yle=3D"color:#008">case</span><span style=3D"color:#000"> </span><span styl=
e=3D"color:#066">0</span><span style=3D"color:#660">:</span><span style=3D"=
color:#000"><br> </span><span style=3D"color:#008">int</span><=
span style=3D"color:#000"> i </span><span style=3D"color:#660">=3D</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#066">5</span><span s=
tyle=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#008">case</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">1</span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"><br> i </span><span style=3D"color:#660">+=3D</span=
><span style=3D"color:#000"> </span><span style=3D"color:#066">5</span><spa=
n style=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span =
style=3D"color:#660">}</span><span style=3D"color:#000"><br></span></div></=
code></div>changing switch to safe switch will silently change meaning of t=
his code and hide bug.<br><br>In my approach this will be simply rejected a=
s invalid.<br><br><br>On Sunday, November 17, 2013 10:15:21 AM UTC+1, Andre=
w Tomazos 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>I'm working on a proposal following the recent switch statement thread, =
about a new Safe Switch Statement intended for the C++17 timeframe.</div><d=
iv><br></div><div>Latest draft is here:</div><div><br></div><a href=3D"http=
s://github.com/AndrewTomazos/cpp-proposals/blob/master/safe_switch.md" targ=
et=3D"_blank">https://github.com/<wbr>AndrewTomazos/cpp-proposals/<wbr>blob=
/master/safe_switch.md</a><br><div><br></div><div>Feedback appreciated. &nb=
sp;Also, if anyone is old enough to vet the History section for accuracy th=
at would be awesome. :)</div><div><br></div></div></blockquote></div></bloc=
kquote></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1994_24147466.1384806398194--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 18 Nov 2013 14:29:29 -0600
Raw View
--f46d0438907908f7bb04eb796af7
Content-Type: text/plain; charset=ISO-8859-1
On 18 November 2013 14:21, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Whether a safe switch is introduced by an attribute such as `[[safe]]
> switch` or a combination of keywords such as `explicit switch` or a new
> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
> have plenty of time to think about that.
>
It isn't a bikeshed. There are vast differences in what you can do with an
attribute (no semantic effects) vs. a new keyword (anything you like), and
it is (IMO) much easier to get attributes added to the standard for
precisely that reason.
--
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/.
--f46d0438907908f7bb04eb796af7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 November 2013 14:21, Andrew Tomazos <span dir=3D"ltr=
"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewto=
mazos@gmail.com</a>></span> wrote:<br><div class=3D"gmail_extra"><div cl=
ass=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">Whether a safe switch is in=
troduced by an attribute such as `[[safe]] switch` or a combination of keyw=
ords such as `explicit switch` or a new keyword such as `safe_switch` is a =
bit of a bikeshed at this point, and we have plenty of time to think about =
that.</div>
</blockquote><div><br></div><div>It isn't a bikeshed.=A0 There are vast=
differences in what you can do with an attribute (no semantic effects) vs.=
a new keyword (anything you like), and it is (IMO) much easier to get attr=
ibutes added to the standard for precisely that reason.<br clear=3D"all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d0438907908f7bb04eb796af7--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 18 Nov 2013 13:13:30 -0800 (PST)
Raw View
------=_Part_2350_16375560.1384809210687
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 18, 2013 9:29:29 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On 18 November 2013 14:21, Andrew Tomazos <andrew...@gmail.com<javascript:>
> > wrote:
>
>> Whether a safe switch is introduced by an attribute such as `[[safe]]
>> switch` or a combination of keywords such as `explicit switch` or a new
>> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
>> have plenty of time to think about that.
>>
>
> It isn't a bikeshed. There are vast differences in what you can do with
> an attribute (no semantic effects) vs. a new keyword (anything you like),
> and it is (IMO) much easier to get attributes added to the standard for
> precisely that reason.
>
Ok. At bare minimum I think everyone agrees we want implicit fallthrough
ill-formed in a safe switch, and assuming that counts as a semantic effect,
then that rules out using an attribute.
--
---
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_2350_16375560.1384809210687
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 18, 2013 9:29:29 PM UTC+1, Nevin ":-)"=
Liber wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
On 18 November 2013 14:21, Andrew Tomazos <span dir=3D"ltr"><<a href=3D"=
javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"OH6PMRmTh-IJ">andre=
w...@gmail.com</a>></span> wrote:<br><div><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">Whether a safe switch is in=
troduced by an attribute such as `[[safe]] switch` or a combination of keyw=
ords such as `explicit switch` or a new keyword such as `safe_switch` is a =
bit of a bikeshed at this point, and we have plenty of time to think about =
that.</div>
</blockquote><div><br></div><div>It isn't a bikeshed. There are vast =
differences in what you can do with an attribute (no semantic effects) vs. =
a new keyword (anything you like), and it is (IMO) much easier to get attri=
butes added to the standard for precisely that reason.<br clear=3D"all">
</div></div></div></div></blockquote><div><br></div><div>Ok. At bare =
minimum I think everyone agrees we want implicit fallthrough ill-formed in =
a safe switch, and assuming that counts as a semantic effect, then that rul=
es out using an attribute.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2350_16375560.1384809210687--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 19 Nov 2013 00:11:34 +0200
Raw View
On 11/18/2013 10:25 PM, Billy O'Neal wrote:
> Perhaps we should consider just recommending programmers use an if /
> else if ladder instead...
>
A long if / else ladder is unlikely to be optimized into a jump table.
Careful construction of switch statements is a way of hinting the
compiler to do its best, even if at times one has to force things by
creating the jump table construct manually.
--
---
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: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 18 Nov 2013 14:18:54 -0800
Raw View
--089e01177567593f2c04eb7af161
Content-Type: text/plain; charset=ISO-8859-1
RE: Jump table:
http://stackoverflow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Nov 18, 2013 at 2:11 PM, George Makrydakis <irrequietus@gmail.com>wrote:
> On 11/18/2013 10:25 PM, Billy O'Neal wrote:
>
>> Perhaps we should consider just recommending programmers use an if / else
>> if ladder instead...
>>
>> A long if / else ladder is unlikely to be optimized into a jump table.
> Careful construction of switch statements is a way of hinting the compiler
> to do its best, even if at times one has to force things by creating the
> jump table construct manually.
>
> --
>
> --- 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/.
--089e01177567593f2c04eb7af161
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>RE: Jump table:</div><div><a href=3D"http://stackover=
flow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054">http:/=
/stackoverflow.com/questions/6805026/is-switch-faster-than-if/6805054#68050=
54</a></div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:11 PM, George =
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" t=
arget=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
On 11/18/2013 10:25 PM, Billy O'Neal wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Perhaps we should consider just recommending programmers use an if / else i=
f ladder instead...<br>
<br>
</blockquote>
A long if / else ladder is unlikely to be optimized into a jump table. Care=
ful construction of switch statements is a way of hinting the compiler to d=
o its best, even if at times one has to force things by creating the jump t=
able construct manually.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</font></span></blockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01177567593f2c04eb7af161--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 18 Nov 2013 16:25:25 -0600
Raw View
--047d7bb04bc2a49a0204eb7b08b3
Content-Type: text/plain; charset=ISO-8859-1
On 18 November 2013 15:13, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>
> Ok. At bare minimum I think everyone agrees we want implicit fallthrough
> ill-formed in a safe switch, and assuming that counts as a semantic effect,
> then that rules out using an attribute.
>
I strongly disagree with that statement.
I think an attribute would be good enough to solve the current issue (and
even then I'm not sure it is worth solving, since compilers already do it
under QoI, but I would probably vote weakly for such a solution), and
anything more (a) is not worth the cost or (b) may introduce a whole new
set of ways for users to get it wrong.
--
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/.
--047d7bb04bc2a49a0204eb7b08b3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 18 November 2013 15:13, Andrew Tomazos <span dir=3D"ltr=
"><<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andrewto=
mazos@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:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><div>Ok. =A0At bare minimum I think everyone=
agrees we want implicit fallthrough ill-formed in a safe switch, and assum=
ing that counts as a semantic effect, then that rules out using an attribut=
e.</div>
</div></blockquote><div><br></div><div>I strongly disagree with that statem=
ent.<br><br></div><div>I think an attribute would be good enough to solve t=
he current issue (and even then I'm not sure it is worth solving, since=
compilers already do it under QoI, but I would probably vote weakly for su=
ch a solution), and anything more (a) is not worth the cost or (b) may intr=
oduce a whole new set of ways for users to get it wrong.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bb04bc2a49a0204eb7b08b3--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Nov 2013 00:29:54 +0200
Raw View
On 19 November 2013 00:25, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 18 November 2013 15:13, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>>
>>
>> Ok. At bare minimum I think everyone agrees we want implicit fallthrough
>> ill-formed in a safe switch, and assuming that counts as a semantic effect,
>> then that rules out using an attribute.
>
>
> I strongly disagree with that statement.
>
> I think an attribute would be good enough to solve the current issue (and
> even then I'm not sure it is worth solving, since compilers already do it
> under QoI, but I would probably vote weakly for such a solution), and
> anything more (a) is not worth the cost or (b) may introduce a whole new set
> of ways for users to get it wrong.
I still think probably everybody would agree that a "safe switch" shouldn't do
fall-through. But not everybody agrees that we need a "safe switch". ;)
I don't know what that "ill-formed" part is doing there, though...
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Mon, 18 Nov 2013 14:50:12 -0800
Raw View
--089e0111ae34e320a504eb7b5ec7
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Nov 18, 2013 at 1:13 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Monday, November 18, 2013 9:29:29 PM UTC+1, Nevin ":-)" Liber wrote:
>
>> On 18 November 2013 14:21, Andrew Tomazos <andrew...@gmail.com> wrote:
>>
>>> Whether a safe switch is introduced by an attribute such as `[[safe]]
>>> switch` or a combination of keywords such as `explicit switch` or a new
>>> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
>>> have plenty of time to think about that.
>>>
>>
>> It isn't a bikeshed. There are vast differences in what you can do with
>> an attribute (no semantic effects) vs. a new keyword (anything you like),
>> and it is (IMO) much easier to get attributes added to the standard for
>> precisely that reason.
>>
>
> Ok. At bare minimum I think everyone agrees we want implicit fallthrough
> ill-formed in a safe switch, and assuming that counts as a semantic effect,
> then that rules out using an attribute.
>
Making code produce an (optional) diagnostic isn't a semantic effect. The
[[deprecated]] and [[noreturn]] attributes do that. If your implementation
wants to provide a way to make that diagnostic an error, that's up to it.
This very quickly gets into the realm of QoI. For instance:
switch (x) {
case 0:
if (b)
return x;
else
return y;
case 1:
Here we "obviously" don't have fallthrough, and a smart compiler would not
warn. What about here:
switch (x) {
case 0:
if (b)
return x;
if (!b)
return y;
case 1:
Determining whether fallthrough can /actually/ happen is trivially
equivalent to the halting problem, and determining whether it can
syntactically happen results in false positives in lots of real-world cases.
--
---
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/.
--089e0111ae34e320a504eb7b5ec7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Nov 18, 2013 at 1:13 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: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">On Monday, November 18, 2013 9:29:29 PM U=
TC+1, Nevin ":-)" Liber wrote:<div class=3D"im">
<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">On 18 November 2013 14:21, Andrew Tomazos=
<span dir=3D"ltr"><<a>andrew...@gmail.com</a>></span> wrote:<br>
<div><div class=3D"gmail_quote">
<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">Whether a safe switch is introduced by an=
attribute such as `[[safe]] switch` or a combination of keywords such as `=
explicit switch` or a new keyword such as `safe_switch` is a bit of a bikes=
hed at this point, and we have plenty of time to think about that.</div>
</blockquote><div><br></div><div>It isn't a bikeshed.=A0 There are vast=
differences in what you can do with an attribute (no semantic effects) vs.=
a new keyword (anything you like), and it is (IMO) much easier to get attr=
ibutes added to the standard for precisely that reason.<br clear=3D"all">
</div></div></div></div></blockquote><div><br></div></div><div>Ok. =A0At ba=
re minimum I think everyone agrees we want implicit fallthrough ill-formed =
in a safe switch, and assuming that counts as a semantic effect, then that =
rules out using an attribute.</div>
</div></blockquote><div><br></div><div>Making code produce an (optional) di=
agnostic isn't a semantic effect. The [[deprecated]] and [[noreturn]] a=
ttributes do that. If your implementation wants to provide a way to make th=
at diagnostic an error, that's up to it.</div>
<div><br>This very quickly gets into the realm of QoI. For instance:</div><=
div><br></div><div>switch (x) {</div><div>case 0:</div><div>=A0 if (b)</div=
><div>=A0 =A0 return x;</div><div>=A0 else</div><div>=A0 =A0 return y;</div=
><div>case 1:</div>
<div><br></div><div>Here we "obviously" don't have fallthroug=
h, and a smart compiler would not warn. What about here:<br></div><div><br>=
</div><div><div>switch (x) {</div><div>case 0:</div><div>=A0 if (b)</div>
<div>=A0 =A0 return x;</div><div>=A0 if (!b)</div><div>=A0 =A0 return y;</d=
iv><div>case 1:</div></div><div><br></div><div>Determining whether fallthro=
ugh can /actually/ happen is trivially equivalent to the halting problem, a=
nd determining whether it can syntactically happen results in false positiv=
es in lots of real-world cases.<br>
</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0111ae34e320a504eb7b5ec7--
.
Author: George Makrydakis <irrequietus@gmail.com>
Date: Tue, 19 Nov 2013 00:55:26 +0200
Raw View
------YWML4GP0BW9S1IDHER5D8Q5FX73OE3
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Your SO reference is practically a verbose elaboration of what "hinting" is=
referring to, albeit incomplete. The argument of deprecating switch statem=
ents in favor of if-else cascades given their already established compiler =
mechanics and likely "hinted" optimizations is extremely weak.
Billy O'Neal <billy.oneal@gmail.com> wrote:
>RE: Jump table:
>http://stackoverflow.com/questions/6805026/is-switch-faster-than-if/680505=
4#6805054
>
>Billy O'Neal
>https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>http://stackoverflow.com/users/82320/billy-oneal
>Malware Response Instructor - BleepingComputer.com
>
>
>On Mon, Nov 18, 2013 at 2:11 PM, George Makrydakis
><irrequietus@gmail.com>wrote:
>
>> On 11/18/2013 10:25 PM, Billy O'Neal wrote:
>>
>>> Perhaps we should consider just recommending programmers use an if /
>else
>>> if ladder instead...
>>>
>>> A long if / else ladder is unlikely to be optimized into a jump
>table.
>> Careful construction of switch statements is a way of hinting the
>compiler
>> to do its best, even if at times one has to force things by creating
>the
>> jump table construct manually.
>>
>> --
>>
>> --- 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 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/.
------YWML4GP0BW9S1IDHER5D8Q5FX73OE3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><p dir=3D"ltr">Your SO reference is practically a =
verbose elaboration of what "hinting" is referring to, albeit incomplete. T=
he argument of deprecating switch statements in favor of if-else cascades g=
iven their already established compiler mechanics and likely "hinted" optim=
izations is extremely weak.</p>
<br><br><div class=3D"gmail_quote">Billy O'Neal <billy.oneal@gmail.c=
om> wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt=
0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir=3D"ltr"><div>RE: Jump table:</div><div><a href=3D"http://stackover=
flow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054">http:/=
/stackoverflow.com/questions/6805026/is-switch-faster-than-if/6805054#68050=
54</a></div>
</div><div class=3D"gmail_extra"><br clear=3D"all" /><div><div dir=3D"ltr">=
<div>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal=
/" target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=
=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">htt=
p://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br /><br /><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:11 PM, Geo=
rge Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.co=
m" target=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br /><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">
On 11/18/2013 10:25 PM, Billy O'Neal wrote:<br />
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Perhaps we should consider just recommending programmers use an if / else i=
f ladder instead...<br />
<br />
</blockquote>
A long if / else ladder is unlikely to be optimized into a jump table. Care=
ful construction of switch statements is a way of hinting the compiler to d=
o its best, even if at times one has to force things by creating the jump t=
able construct manually.<span class=3D"HOEnZb"><font color=3D"#888888"><br =
/>
<br />
-- <br />
<br />
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br />
</font></span></blockquote></div><br /></div>
<p></p>
</blockquote></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------YWML4GP0BW9S1IDHER5D8Q5FX73OE3--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 18 Nov 2013 16:01:08 -0800 (PST)
Raw View
------=_Part_2476_23008445.1384819268843
Content-Type: text/plain; charset=ISO-8859-1
On Monday, November 18, 2013 11:50:12 PM UTC+1, Richard Smith wrote:
>
> On Mon, Nov 18, 2013 at 1:13 PM, Andrew Tomazos <andrew...@gmail.com<javascript:>
> > wrote:
>
>> On Monday, November 18, 2013 9:29:29 PM UTC+1, Nevin ":-)" Liber wrote:
>>
>>> On 18 November 2013 14:21, Andrew Tomazos <andrew...@gmail.com> wrote:
>>>
>>>> Whether a safe switch is introduced by an attribute such as `[[safe]]
>>>> switch` or a combination of keywords such as `explicit switch` or a new
>>>> keyword such as `safe_switch` is a bit of a bikeshed at this point, and we
>>>> have plenty of time to think about that.
>>>>
>>>
>>> It isn't a bikeshed. There are vast differences in what you can do with
>>> an attribute (no semantic effects) vs. a new keyword (anything you like),
>>> and it is (IMO) much easier to get attributes added to the standard for
>>> precisely that reason.
>>>
>>
>> Ok. At bare minimum I think everyone agrees we want implicit fallthrough
>> ill-formed in a safe switch, and assuming that counts as a semantic effect,
>> then that rules out using an attribute.
>>
>
> Making code produce an (optional) diagnostic isn't a semantic effect. The
> [[deprecated]] and [[noreturn]] attributes do that. If your implementation
> wants to provide a way to make that diagnostic an error, that's up to it.
>
Determining whether fallthrough can /actually/ happen is trivially
> equivalent to the halting problem, and determining whether it can
> syntactically happen results in false positives in lots of real-world cases.
>
Ok, that is a good point. It's exactly the same as determining whether the
definition of a function returning T can flow off the end, resulting in
undefined behaviour:
"Flowing off the end of a function is equivalent to a return with no value;
this results in undefined behavior in a value-returning function."
In the vast majority of cases in implementations the [-Wreturn-type]
diagnostic is accurate, but I agree that false positives and false
negatives are possible and need to have a contingency.
The main problem we face however is that in 3% of existing switches,
detectable implicit fallthrough is used intentionally as a feature -
providing cover for detectable accidental fallthrough. We cannot therefore
emit a diagnostic for implicit fallthrough in existing switches, because
all that existing code will fire a warning, and noone is going to go
through the 40+ years of exisiting code and update it all.
Hence the reasoning that we need to firstly provide a way to explicitly
state fallthrough (the goto case statement), and then we need to provide a
safe version of the switch statement to be used in new code where
detectable implicit fallthrough generates a diagnostic.
Therefore, for the false positives the programmer can put in a unneeded
break or goto case to suppress the diagnostic, and for the false negatives
it will continue to be an accidental fallthrough bug as it is today. The
important thing is that 99.9% of the accidental fallthrough bugs are
avoided when safe switches are used in new 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/.
------=_Part_2476_23008445.1384819268843
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 18, 2013 11:50:12 PM UTC+1, Richard Sm=
ith 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">On =
Mon, Nov 18, 2013 at 1:13 PM, Andrew Tomazos <span dir=3D"ltr"><<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"p3R9d2Q80o8J">a=
ndrew...@gmail.com</a>></span> wrote:<br><div><div class=3D"gmail_quote"=
>
<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">On Monday, November 18, 2013 9:29:29 PM U=
TC+1, Nevin ":-)" Liber wrote:<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);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr">On 18 November 2013 14:21, Andrew Tomazos=
<span dir=3D"ltr"><<a>andrew...@gmail.com</a>></span> wrote:<br>
<div><div class=3D"gmail_quote">
<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">Whether a safe switch is introduced by an=
attribute such as `[[safe]] switch` or a combination of keywords such as `=
explicit switch` or a new keyword such as `safe_switch` is a bit of a bikes=
hed at this point, and we have plenty of time to think about that.</div>
</blockquote><div><br></div><div>It isn't a bikeshed. There are vast =
differences in what you can do with an attribute (no semantic effects) vs. =
a new keyword (anything you like), and it is (IMO) much easier to get attri=
butes added to the standard for precisely that reason.<br clear=3D"all">
</div></div></div></div></blockquote><div><br></div></div><div>Ok. At=
bare minimum I think everyone agrees we want implicit fallthrough ill-form=
ed in a safe switch, and assuming that counts as a semantic effect, then th=
at rules out using an attribute.</div>
</div></blockquote><div><br></div><div>Making code produce an (optional) di=
agnostic isn't a semantic effect. The [[deprecated]] and [[noreturn]] attri=
butes do that. If your implementation wants to provide a way to make that d=
iagnostic an error, that's up to it.</div></div></div></div></blockquote><b=
lockquote 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; padding-left: 1ex;"> </blockquote><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div>Determining whether fallthrough can /actually/ happen is trivially equ=
ivalent to the halting problem, and determining whether it can syntacticall=
y happen results in false positives in lots of real-world cases.<br></div><=
/div></div></div></blockquote><div><br></div><div>Ok, that is a good point.=
It's exactly the same as determining whether the definition of a fun=
ction returning T can flow off the end, resulting in undefined behaviour:</=
div><div><br></div><div>"Flowing off the end of a function is equivalent to=
a return with no value; this results in undefined behavior in a value-retu=
rning function."</div><div><br></div><div>In the vast majority of cases in =
implementations the [-Wreturn-type] diagnostic is accurate, but I agree tha=
t false positives and false negatives are possible and need to have a conti=
ngency.</div><div><br></div><div>The main problem we face however is that i=
n 3% of existing switches, detectable implicit fallthrough is used intentio=
nally as a feature - providing cover for detectable accidental fallthrough.=
We cannot therefore emit a diagnostic for implicit fallthrough in ex=
isting switches, because all that existing code will fire a warning, and no=
one is going to go through the 40+ years of exisiting code and update it al=
l.</div><div><br></div><div>Hence the reasoning that we need to firstly pro=
vide a way to explicitly state fallthrough (the goto case statement), and t=
hen we need to provide a safe version of the switch statement to be used in=
new code where detectable implicit fallthrough generates a diagnostic.</di=
v><div><br></div><div>Therefore, for the false positives the programmer can=
put in a unneeded break or goto case to suppress the diagnostic, and for t=
he false negatives it will continue to be an accidental fallthrough bug as =
it is today. The important thing is that 99.9% of the accidental fall=
through bugs are avoided when safe switches are used in new code.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2476_23008445.1384819268843--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 18 Nov 2013 16:01:40 -0800
Raw View
--089e013d0db0ecfa8604eb7c60ba
Content-Type: text/plain; charset=ISO-8859-1
My point in that answer is that
1. I see lots of people claim this jump table thing on switches.
2. I have never seen an actual program have a performance advantage by
using a switch over an if/elseif ladder.
3. I have never seen an actual compiler generate the supposed "jump table"
(though admittedly I don't make a habit of examining lots of assembly code).
If someone would show data describing an actual program compiled with
a modern compiler where the choice of switch vs. if made a measurable
performance difference, then I could be convinced otherwise. Modern
compilers already do data-dependence analysis in order to enable features
like auto-vectorization and auto-parallelization; and I find it hard to
believe that such machinery couldn't be useful for proving switch-like
characteristics about an if/elseif ladder. Moreover, from the 10,000 foot
view of what I've seen of e.g. LLVM IR, there's no way for the frontend to
express that this is a switch statement to the optimizer, so it must
already be figuring this kind of stuff out implicitly. So... unless someone
can show data showing otherwise, I remain unconvinced that the supposed
"jump table" optimization which can be applied to a switch actually results
in faster code on modern compilers.
The argument we started with was "language construct X is unsafe, we should
introduce a new construct, Y," my comment is merely "the language already
has an alternative to X, and that alternative is Z". If / elseif already
offers a complete solution to this problem:
1. It solves the cross variable scope issue.
2. Does not allow implicit fallthrough.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Nov 18, 2013 at 2:55 PM, George Makrydakis <irrequietus@gmail.com>wrote:
> Your SO reference is practically a verbose elaboration of what "hinting"
> is referring to, albeit incomplete. The argument of deprecating switch
> statements in favor of if-else cascades given their already established
> compiler mechanics and likely "hinted" optimizations is extremely weak.
>
>
> Billy O'Neal <billy.oneal@gmail.com> wrote:
>>
>> RE: Jump table:
>>
>> http://stackoverflow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054
>>
>> Billy O'Neal
>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>> http://stackoverflow.com/users/82320/billy-oneal
>> Malware Response Instructor - BleepingComputer.com
>>
>>
>> On Mon, Nov 18, 2013 at 2:11 PM, George Makrydakis <irrequietus@gmail.com
>> > wrote:
>>
>>> On 11/18/2013 10:25 PM, Billy O'Neal wrote:
>>>
>>>> Perhaps we should consider just recommending programmers use an if /
>>>> else if ladder instead...
>>>>
>>>> A long if / else ladder is unlikely to be optimized into a jump table.
>>> Careful construction of switch statements is a way of hinting the compiler
>>> to do its best, even if at times one has to force things by creating the
>>> jump table construct manually.
>>>
>>>
>>> --
>>>
>>> --- 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/.
>
--
---
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/.
--089e013d0db0ecfa8604eb7c60ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>My point in that answer is that</div><div>1. I see lo=
ts of people claim this jump table thing on switches.</div><div>2. I have n=
ever seen an actual program have a performance advantage by using a switch =
over an if/elseif ladder.</div>
<div>3. I have never seen an actual compiler generate the supposed "ju=
mp table" (though admittedly I don't make a habit of examining lot=
s of assembly code).</div><div><br></div><div>If someone would show data de=
scribing an actual program compiled with a=A0modern compiler where the choi=
ce of switch vs. if made a measurable performance difference, then I could =
be convinced otherwise. Modern compilers already do data-dependence analysi=
s in order to enable features like auto-vectorization and auto-parallelizat=
ion; and I find it hard to believe that such machinery couldn't be usef=
ul for proving switch-like characteristics about an if/elseif ladder. Moreo=
ver, from the 10,000 foot view of what I've seen of e.g. LLVM IR, there=
's no way for the frontend to express that this is a switch statement t=
o the optimizer, so it must already be figuring this kind of stuff out impl=
icitly. So... unless someone can show data showing otherwise, I remain unco=
nvinced that the supposed "jump table" optimization which can be =
applied to a switch actually results in faster code on modern compilers.</d=
iv>
<div><br></div><div>The argument we started with was "language constru=
ct X is unsafe, we should introduce a new construct, Y," my comment is=
merely "the language already has an alternative to X, and that altern=
ative is Z".=A0If / elseif already offers a complete solution to this =
problem:</div>
<div>1. It solves the cross variable scope issue.</div><div>2. Does not all=
ow implicit fallthrough.</div><div><br></div></div><div class=3D"gmail_extr=
a"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div>=
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:55 PM, George =
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" t=
arget=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div><p dir=3D"ltr">Your SO reference is practically a verbose elaboration =
of what "hinting" is referring to, albeit incomplete. The argumen=
t of deprecating switch statements in favor of if-else cascades given their=
already established compiler mechanics and likely "hinted" optim=
izations is extremely weak.</p>
<br><br><div class=3D"gmail_quote">Billy O'Neal <<a href=3D"mailto:b=
illy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">
<div dir=3D"ltr"><div>RE: Jump table:</div><div><a href=3D"http://stackover=
flow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054" target=
=3D"_blank">http://stackoverflow.com/questions/6805026/is-switch-faster-tha=
n-if/6805054#6805054</a></div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:11 PM, George =
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" t=
arget=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid">
On 11/18/2013 10:25 PM, Billy O'Neal wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Perhaps we should consider just recommending programmers use an if / else i=
f ladder instead...<br>
<br>
</blockquote>
A long if / else ladder is unlikely to be optimized into a jump table. Care=
ful construction of switch statements is a way of hinting the compiler to d=
o its best, even if at times one has to force things by creating the jump t=
able construct manually.<div class=3D"im">
<span><font color=3D"#888888"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</font></span></div></blockquote></div><br></div>
<p></p>
</blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d0db0ecfa8604eb7c60ba--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 18 Nov 2013 17:17:15 -0800 (PST)
Raw View
------=_Part_2617_25595713.1384823835132
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, November 19, 2013 1:01:40 AM UTC+1, Billy O'Neal wrote:
>
> My point in that answer is that
> 1. I see lots of people claim this jump table thing on switches.
> 2. I have never seen an actual program have a performance advantage by
> using a switch over an if/elseif ladder.
>
3. I have never seen an actual compiler generate the supposed "jump table"
> (though admittedly I don't make a habit of examining lots of assembly code).
> If someone would show data describing an actual program compiled with
> a modern compiler where the choice of switch vs. if made a measurable
> performance difference, then I could be convinced otherwise. Modern
> compilers already do data-dependence analysis in order to enable features
> like auto-vectorization and auto-parallelization; and I find it hard to
> believe that such machinery couldn't be useful for proving switch-like
> characteristics about an if/elseif ladder. Moreover, from the 10,000 foot
> view of what I've seen of e.g. LLVM IR, there's no way for the frontend to
> express that this is a switch statement to the optimizer,
>
A switch statement is expressed by clang in LLVM IR using a `switch`
instruction:
http://llvm.org/docs/LangRef.html#switch-instruction
This is otherwise called a multi-way branch.
2. Does not allow implicit fallthrough.
>
An if-else-chain doesn't allow explicit fallthrough either.
To give you some idea, the clang source itself alone, not including LLVM,
contains approximately 2,500 switch statements. The switch statement is
not going away any time soon.
--
---
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_2617_25595713.1384823835132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 19, 2013 1:01:40 AM UTC+1, Billy O'Ne=
al 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=
>My point in that answer is that</div><div>1. I see lots of people claim th=
is jump table thing on switches.</div><div>2. I have never seen an actual p=
rogram have a performance advantage by using a switch over an if/elseif lad=
der.</div></div></blockquote><div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: r=
gb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">3. I have =
never seen an actual compiler generate the supposed "jump table" (though ad=
mittedly I don't make a habit of examining lots of assembly code).</blockqu=
ote></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); border-=
left-style: solid; padding-left: 1ex;"><br></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div>If someone would show dat=
a describing an actual program compiled with a modern compiler where t=
he choice of switch vs. if made a measurable performance difference, then I=
could be convinced otherwise. Modern compilers already do data-dependence =
analysis in order to enable features like auto-vectorization and auto-paral=
lelization; and I find it hard to believe that such machinery couldn't be u=
seful for proving switch-like characteristics about an if/elseif ladder. Mo=
reover, from the 10,000 foot view of what I've seen of e.g. LLVM IR, there'=
s no way for the frontend to express that this is a switch statement to the=
optimizer,</div></div></blockquote><div><br></div><div>A switch statement =
is expressed by clang in LLVM IR using a `switch` instruction:<br></div><di=
v><br></div><div><a href=3D"http://llvm.org/docs/LangRef.html#switch-instru=
ction">http://llvm.org/docs/LangRef.html#switch-instruction</a><br></div><d=
iv><br></div><div>This is otherwise called a multi-way branch.</div><div><b=
r></div><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>=
2. Does not allow implicit fallthrough.<br></div></div></blockquote><div>&n=
bsp;</div><div>An if-else-chain doesn't allow explicit fallthrough either.<=
/div><div><br></div><div>To give you some idea, the clang source itself alo=
ne, not including LLVM, contains approximately 2,500 switch statements. &nb=
sp;The switch statement is not going away any time soon.</div><div><br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2617_25595713.1384823835132--
.
Author: =?ISO-8859-1?Q?Diego_S=E1nchez?= <dsde71@gmail.com>
Date: Tue, 19 Nov 2013 10:47:02 +0100
Raw View
--f46d04440284f40dfd04eb848b18
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
an if/else ladder is far harder to read and, for newbies, far harder to
interpret. It is also prone to subtle errors if you don't properly brace. I
can't see it as a better solution than what's bein proposed here.
Besides, if you switch on an enum and add a new value to said enum, the
compiler can emit a warning for every missed case; something far harder to
do in an if/else ladder.
Just my two cents.
El 19/11/2013 01:02, "Billy O'Neal" <billy.oneal@gmail.com> escribi=F3:
> My point in that answer is that
> 1. I see lots of people claim this jump table thing on switches.
> 2. I have never seen an actual program have a performance advantage by
> using a switch over an if/elseif ladder.
> 3. I have never seen an actual compiler generate the supposed "jump table=
"
> (though admittedly I don't make a habit of examining lots of assembly cod=
e).
>
> If someone would show data describing an actual program compiled with
> a modern compiler where the choice of switch vs. if made a measurable
> performance difference, then I could be convinced otherwise. Modern
> compilers already do data-dependence analysis in order to enable features
> like auto-vectorization and auto-parallelization; and I find it hard to
> believe that such machinery couldn't be useful for proving switch-like
> characteristics about an if/elseif ladder. Moreover, from the 10,000 foot
> view of what I've seen of e.g. LLVM IR, there's no way for the frontend t=
o
> express that this is a switch statement to the optimizer, so it must
> already be figuring this kind of stuff out implicitly. So... unless someo=
ne
> can show data showing otherwise, I remain unconvinced that the supposed
> "jump table" optimization which can be applied to a switch actually resul=
ts
> in faster code on modern compilers.
>
> The argument we started with was "language construct X is unsafe, we
> should introduce a new construct, Y," my comment is merely "the language
> already has an alternative to X, and that alternative is Z". If / elseif
> already offers a complete solution to this problem:
> 1. It solves the cross variable scope issue.
> 2. Does not allow implicit fallthrough.
>
>
> Billy O'Neal
> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
> http://stackoverflow.com/users/82320/billy-oneal
> Malware Response Instructor - BleepingComputer.com
>
>
> On Mon, Nov 18, 2013 at 2:55 PM, George Makrydakis <irrequietus@gmail.com=
>wrote:
>
>> Your SO reference is practically a verbose elaboration of what "hinting"
>> is referring to, albeit incomplete. The argument of deprecating switch
>> statements in favor of if-else cascades given their already established
>> compiler mechanics and likely "hinted" optimizations is extremely weak.
>>
>>
>> Billy O'Neal <billy.oneal@gmail.com> wrote:
>>>
>>> RE: Jump table:
>>>
>>> http://stackoverflow.com/questions/6805026/is-switch-faster-than-if/680=
5054#6805054
>>>
>>> Billy O'Neal
>>> https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
>>> http://stackoverflow.com/users/82320/billy-oneal
>>> Malware Response Instructor - BleepingComputer.com
>>>
>>>
>>> On Mon, Nov 18, 2013 at 2:11 PM, George Makrydakis <
>>> irrequietus@gmail.com> wrote:
>>>
>>>> On 11/18/2013 10:25 PM, Billy O'Neal wrote:
>>>>
>>>>> Perhaps we should consider just recommending programmers use an if /
>>>>> else if ladder instead...
>>>>>
>>>>> A long if / else ladder is unlikely to be optimized into a jump
>>>> table. Careful construction of switch statements is a way of hinting t=
he
>>>> compiler to do its best, even if at times one has to force things by
>>>> creating the jump table construct manually.
>>>>
>>>>
>>>> --
>>>>
>>>> --- 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 Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> 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/.
>
--=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/.
--f46d04440284f40dfd04eb848b18
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_quote" style>an if/else ladder is far =
harder to read and, for newbies, far harder to interpret. It is also prone =
to subtle errors if you don't properly brace. I can't see it as a b=
etter solution than what's bein proposed here.</div>
<div class=3D"gmail_quote" style><br></div><div class=3D"gmail_quote" style=
>Besides, if you switch on an enum and add a new value to said enum, the co=
mpiler can emit a warning for every missed case; something far harder to do=
in an if/else ladder.</div>
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote" style>Just =
my two cents.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">El 19/11/2013 01:02, "Billy O'Neal" <<a href=3D"ma=
ilto:billy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>>=
escribi=F3:<br type=3D"attribution">
<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>My point in that answer is that</div><div>1. I see lo=
ts of people claim this jump table thing on switches.</div><div>2. I have n=
ever seen an actual program have a performance advantage by using a switch =
over an if/elseif ladder.</div>
<div>3. I have never seen an actual compiler generate the supposed "ju=
mp table" (though admittedly I don't make a habit of examining lot=
s of assembly code).</div><div><br></div><div>If someone would show data de=
scribing an actual program compiled with a=A0modern compiler where the choi=
ce of switch vs. if made a measurable performance difference, then I could =
be convinced otherwise. Modern compilers already do data-dependence analysi=
s in order to enable features like auto-vectorization and auto-parallelizat=
ion; and I find it hard to believe that such machinery couldn't be usef=
ul for proving switch-like characteristics about an if/elseif ladder. Moreo=
ver, from the 10,000 foot view of what I've seen of e.g. LLVM IR, there=
's no way for the frontend to express that this is a switch statement t=
o the optimizer, so it must already be figuring this kind of stuff out impl=
icitly. So... unless someone can show data showing otherwise, I remain unco=
nvinced that the supposed "jump table" optimization which can be =
applied to a switch actually results in faster code on modern compilers.</d=
iv>
<div><br></div><div>The argument we started with was "language constru=
ct X is unsafe, we should introduce a new construct, Y," my comment is=
merely "the language already has an alternative to X, and that altern=
ative is Z".=A0If / elseif already offers a complete solution to this =
problem:</div>
<div>1. It solves the cross variable scope issue.</div><div>2. Does not all=
ow implicit fallthrough.</div><div><br></div></div><div class=3D"gmail_extr=
a"><br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div>=
<a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://git=
hub.com/BillyONeal/</a></div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div><div>Mal=
ware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:55 PM, George =
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" t=
arget=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div><p dir=3D"ltr">Your SO reference is practically a verbose elaboration =
of what "hinting" is referring to, albeit incomplete. The argumen=
t of deprecating switch statements in favor of if-else cascades given their=
already established compiler mechanics and likely "hinted" optim=
izations is extremely weak.</p>
<br><br><div class=3D"gmail_quote">Billy O'Neal <<a href=3D"mailto:b=
illy.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>> wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;paddin=
g-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-=
left-style:solid">
<div dir=3D"ltr"><div>RE: Jump table:</div><div><a href=3D"http://stackover=
flow.com/questions/6805026/is-switch-faster-than-if/6805054#6805054" target=
=3D"_blank">http://stackoverflow.com/questions/6805026/is-switch-faster-tha=
n-if/6805054#6805054</a></div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 2:11 PM, George =
Makrydakis <span dir=3D"ltr"><<a href=3D"mailto:irrequietus@gmail.com" t=
arget=3D"_blank">irrequietus@gmail.com</a>></span> wrote:<br><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;b=
order-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:s=
olid">
On 11/18/2013 10:25 PM, Billy O'Neal wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding=
-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-l=
eft-style:solid">
Perhaps we should consider just recommending programmers use an if / else i=
f ladder instead...<br>
<br>
</blockquote>
A long if / else ladder is unlikely to be optimized into a jump table. Care=
ful construction of switch statements is a way of hinting the compiler to d=
o its best, even if at times one has to force things by creating the jump t=
able construct manually.<div>
<span><font color=3D"#888888"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>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/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</font></span></div></blockquote></div><br></div>
<p></p>
</blockquote></div></div><div><div>
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" 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>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--f46d04440284f40dfd04eb848b18--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Nov 2013 12:21:16 +0200
Raw View
On 19 November 2013 03:17, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> 2. Does not allow implicit fallthrough.
>
>
> An if-else-chain doesn't allow explicit fallthrough either.
#include <iostream>
int main()
{
if (true)
goto orly;
else {
orly:
std::cout << "I think you're wrong about that." << std::endl;
}
}
>
> To give you some idea, the clang source itself alone, not including LLVM,
> contains approximately 2,500 switch statements. The switch statement is not
> going away any time soon.
I fail to see how it's the right fix to add a new switch statement that is safer
but ever so subtly different.
--
---
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: Tue, 19 Nov 2013 14:03:02 +0100
Raw View
--485b3970d6e2e597bb04eb8748fb
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Nov 19, 2013 at 11:21 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> > To give you some idea, the clang source itself alone, not including LLVM,
>
> contains approximately 2,500 switch statements. The switch statement is
> not
> > going away any time soon.
>
> I fail to see how it's the right fix to add a new switch statement that is
> safer
> but ever so subtly different.
>
It's not clear whether you are complaining that (a) the difference is too
subtle, or (b) that there is any difference at all.
Assuming you meant (a) I can design a new switch statement that is even
more different than the old one if you like:
constexpr int a = 1;
switch (x)
case 1, 2 {
if (y < z)
goto case a+3;
z = y;
// implicit break
} case 4 {
while (n > 10)
{
n /= z;
m++;
if (m > 100)
break; // explicit break
}
if (n == 5)
goto case a;
goto case 8; // explicit fallthrough
} case 8
std::cout << "good";
default
throw logic_error("bad x");
This can be distinguished from the old syntax by the lack of the opening
brace and the missing colon after the first case, so the old and new syntax
can coexist.
It is structured semantically the same as a safe switch and in the way most
people use switches today, like a state machine or a set of coroutines
(whether surrounded by an outer loop or not).
But I don't think this is a good idea, because we have 40+ years grooving
everyone on the B syntax and it has spread to the majority of the top 10
languages on the planet. Hence I don't think we should change the syntax
and semantics in a new version of the switch statement except where
absolutely necessary for very specific design reasons - and certainly not
in way that would effect 97% of current use. This was one of the design
goals of the safe switch. The subtle difference is intentional. A safe
switch is almost a proper subset of a normal switch statement.
Assuming you meant (b), then it is not possible to fix the accidental
implicit fallthrough bug without making at least some changes in a new
version - and we can't make changes to the old version (such as making
implicit fallthrough ill-formed / undefined), because no-one is going to go
through and update all the old code - and yes, of course the accidental
fallthrough bug is worth fixing in new code. They didn't decide to do it
exactly the way I'm suggesting (no implicit fallthrough / goto case) in C#
just for fun. And goto case was invented prior to B in the sixties, it's
not some crazy new untested idea.
--
---
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/.
--485b3970d6e2e597bb04eb8748fb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Nov 19, 2013 at 11:21 AM, Ville Voutilainen <span dir=3D"ltr"><<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@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 class=3D"im">> To give you some idea=
, the clang source itself alone, not including LLVM,<br></div></blockquote>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div class=3D"im">
> contains approximately 2,500 switch statements. =A0The switch statemen=
t is not<br>
> going away any time soon.<br>
<br>
</div>I fail to see how it's the right fix to add a new switch statemen=
t that is safer<br>
but ever so subtly different.<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><br>=
</div><div class=3D"gmail_extra">It's not clear whether you are complai=
ning that (a) the difference is too subtle, or (b) that there is any differ=
ence at all.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Assuming yo=
u meant (a) I can design a new switch statement that is even more different=
than the old one if you like:</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">
=A0 =A0 constexpr int a =3D 1;</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">=A0 =A0 switch (x)</div><div class=3D"gmail_extra"=
>=A0 =A0 case 1, 2 {</div><div class=3D"gmail_extra">=A0 =A0 =A0 =A0 if (y =
< z)</div><div class=3D"gmail_extra">
=A0 =A0 =A0 =A0 =A0 =A0 goto case a+3;</div><div class=3D"gmail_extra">=A0 =
=A0 =A0 =A0 z =3D y;</div><div class=3D"gmail_extra">=A0 =A0 =A0 =A0 // imp=
licit break</div><div class=3D"gmail_extra">=A0 =A0 } case 4 {</div><div cl=
ass=3D"gmail_extra">=A0 =A0 =A0 =A0 while (n > 10)</div>
<div class=3D"gmail_extra">=A0 =A0 =A0 =A0 {</div><div class=3D"gmail_extra=
">=A0 =A0 =A0 =A0 =A0 =A0 n /=3D z;</div><div class=3D"gmail_extra">=A0 =A0=
=A0 =A0 =A0 =A0 m++;</div><div class=3D"gmail_extra">=A0 =A0 =A0 =A0 =A0 =
=A0 if (m > 100)</div><div class=3D"gmail_extra">=A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0 break; // explicit break</div>
<div class=3D"gmail_extra">=A0 =A0 =A0 =A0 }</div><div class=3D"gmail_extra=
">=A0 =A0 =A0 =A0 if (n =3D=3D 5)</div><div class=3D"gmail_extra">=A0 =A0 =
=A0 =A0 =A0 =A0 goto case a;</div><div class=3D"gmail_extra"><br></div><div=
class=3D"gmail_extra">=A0 =A0 =A0 =A0 goto case 8; // explicit fallthrough=
</div>
<div class=3D"gmail_extra">=A0 =A0 } case 8<br></div><div class=3D"gmail_ex=
tra">=A0 =A0 =A0 =A0 std::cout << "good";</div><div class=
=3D"gmail_extra">=A0 =A0 default<br></div><div class=3D"gmail_extra">=A0 =
=A0 =A0 =A0 throw logic_error("bad x");</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">This can be=
distinguished from the old syntax by the lack of the opening brace and the=
missing colon after the first case, so the old and new syntax can coexist.=
</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">It is struc=
tured semantically the same as a safe switch and in the way most people use=
switches today, like a state machine or a set of coroutines (whether surro=
unded by an outer loop or not).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">But I don&#=
39;t think this is a good idea, because we have 40+ years grooving everyone=
on the B syntax and it has spread to the majority of the top 10 languages =
on the planet. =A0Hence I don't think we should change the syntax and s=
emantics in a new version of the switch statement except where absolutely n=
ecessary for very specific design reasons - and certainly not in way that w=
ould effect 97% of current use. =A0This was one of the design goals of the =
safe switch. =A0The subtle difference is intentional. =A0A safe switch is a=
lmost a proper subset of a normal switch statement.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Assuming yo=
u meant (b), then it is not possible to fix the accidental implicit fallthr=
ough bug without making at least some changes in a new version - and we can=
't make changes to the old version (such as making implicit fallthrough=
ill-formed / undefined), because no-one is going to go through and update =
all the old code - and yes, of course the accidental fallthrough bug is wor=
th fixing in new code. =A0They didn't decide to do it exactly the way I=
'm suggesting (no implicit fallthrough / goto case) in C# just for fun.=
=A0And goto case was invented prior to B in the sixties, it's not some=
crazy new untested idea.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--485b3970d6e2e597bb04eb8748fb--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Nov 2013 15:09:51 +0200
Raw View
On 19 November 2013 15:03, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 11:21 AM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
>>
>> > To give you some idea, the clang source itself alone, not including
>> > LLVM,
>>
>> > contains approximately 2,500 switch statements. The switch statement is
>> > not
>> > going away any time soon.
>>
>> I fail to see how it's the right fix to add a new switch statement that is
>> safer
>> but ever so subtly different.
>
>
> It's not clear whether you are complaining that (a) the difference is too
> subtle, or (b) that there is any difference at all.
I would prefer not calling it switch-case. So yes, (a).
> But I don't think this is a good idea, because we have 40+ years grooving
> everyone on the B syntax and it has spread to the majority of the top 10
> languages on the planet. Hence I don't think we should change the syntax
> and semantics in a new version of the switch statement except where
> absolutely necessary for very specific design reasons - and certainly not in
> way that would effect 97% of current use. This was one of the design goals
> of the safe switch. The subtle difference is intentional. A safe switch is
> almost a proper subset of a normal switch statement.
The subtler the difference is, the more likely it is that people accidentally
write a "legacy" switch rather than the new one. And then we get back to
square one, which is accidental bugs.
--
---
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: Tue, 19 Nov 2013 05:16:10 -0800 (PST)
Raw View
------=_Part_184_33334320.1384866970737
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, November 19, 2013 2:09:51 PM UTC+1, Ville Voutilainen wrote:
>
> >> I fail to see how it's the right fix to add a new switch statement that
> is
> >> safer
> >> but ever so subtly different.
> >
> > It's not clear whether you are complaining that (a) the difference is
> too
> > subtle, or (b) that there is any difference at all.
>
> I would prefer not calling it switch-case. So yes, (a).
What would you prefer calling it then?
--
---
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_184_33334320.1384866970737
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 19, 2013 2:09:51 PM UTC+1, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">>> I fail =
to see how it's the right fix to add a new switch statement that is
<br>>> safer
<br>>> but ever so subtly different.
<br>>
<br>> It's not clear whether you are complaining that (a) the difference=
is too
<br>> subtle, or (b) that there is any difference at all.
<br>
<br>I would prefer not calling it switch-case. So yes, (a). </blockquote><d=
iv><br></div><div>What would you prefer calling it then?</div><div><br></di=
v></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_184_33334320.1384866970737--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Nov 2013 15:35:32 +0200
Raw View
On 19 November 2013 15:16, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Tuesday, November 19, 2013 2:09:51 PM UTC+1, Ville Voutilainen wrote:
>>
>> >> I fail to see how it's the right fix to add a new switch statement that
>> >> is
>> >> safer
>> >> but ever so subtly different.
>> >
>> > It's not clear whether you are complaining that (a) the difference is
>> > too
>> > subtle, or (b) that there is any difference at all.
>>
>> I would prefer not calling it switch-case. So yes, (a).
>
>
> What would you prefer calling it then?
"cond", since such a switch-case-like construct exists in other languages like
lisp without fall-through. I don't have a good name for the cases themselves.
In library implementations I have written for solving this sort of a problem,
I just had the case values as arguments of a variadic function, looks roughly
like
super_case(whatever,
4, [](){
/*code for case 4 */
},
5, [](){
/* code for case 5 */
});
Replacing super_case with cond gets pretty close. All this works with precisely
zero language changes and can switch on anything that is EqualityComparable.
It doesn't do the "jump table", though. I don't propose that that
syntax is ready
for wide consumption, because it doesn't have any kind of case labels, so
it's error-prone. cond-condval rather than switch-case?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 02:21:11 -0800 (PST)
Raw View
------=_Part_115_29695339.1384942871931
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, November 19, 2013 2:35:32 PM UTC+1, Ville Voutilainen wrote:
>
> cond-condval rather than switch-case?
>
So you mean it look like this then:
cond (x)
condval 1, 2 {
if (y < z)
goto cond a+3;
z = y;
// implicit break
} condval 4 {
while (n > 10)
{
n /= z;
m++;
if (m > 100)
break; // explicit break
}
if (n == 5)
goto cond a;
goto cond 8; // explicit fallthrough
} condval 8
std::cout << "good";
default
throw logic_error("bad x");
While the condval could be a context-sensetive keyword, I don't think cond
can be made into a full keyword (as it would need to be to introduce a
statement), it is already used as an identifier frequently, and would
invalidate old 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/.
------=_Part_115_29695339.1384942871931
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, November 19, 2013 2:35:32 PM UTC+1, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">cond-condval rat=
her than switch-case?
<br></blockquote><div><br></div><div>So you mean it look like this then:</d=
iv><div><br></div><div><div> cond (x)</div><div> condval =
1, 2 {</div><div> if (y < z)</div><div> =
goto cond a+3;</div><div> =
z =3D y;</div><div> // implicit br=
eak</div><div> } condval 4 {</div><div> =
while (n > 10)</div><div> {</d=
iv><div> n /=3D z;</div><div> =
; m++;</div><div> &n=
bsp; if (m > 100)</div><div> &n=
bsp; break; // explicit break</div><div> =
}</div><div> if (n =3D=3D 5)</div>=
<div> goto cond a;</div>=
<div><br></div><div> goto cond 8; // e=
xplicit fallthrough</div><div> } condval 8<br></div>=
<div> std::cout << "good";</div><div> =
; default<br></div><div> throw logic_erro=
r("bad x");</div></div><div><br></div><div>While the condval could be a con=
text-sensetive keyword, I don't think cond can be made into a full keyword =
(as it would need to be to introduce a statement), it is already used as an=
identifier frequently, and would invalidate old code.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_115_29695339.1384942871931--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Nov 2013 12:38:01 +0200
Raw View
On 20 November 2013 12:21, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> On Tuesday, November 19, 2013 2:35:32 PM UTC+1, Ville Voutilainen wrote:
>>
>> cond-condval rather than switch-case?
>
>
> So you mean it look like this then:
>
> cond (x)
> condval 1, 2 {
> if (y < z)
> goto cond a+3;
> z = y;
> // implicit break
> } condval 4 {
> while (n > 10)
> {
> n /= z;
> m++;
> if (m > 100)
> break; // explicit break
> }
> if (n == 5)
> goto cond a;
>
> goto cond 8; // explicit fallthrough
> } condval 8
> std::cout << "good";
> default
> throw logic_error("bad x");
>
> While the condval could be a context-sensetive keyword, I don't think cond
> can be made into a full keyword (as it would need to be to introduce a
> statement), it is already used as an identifier frequently, and would
> invalidate old code.
Yep. That is indeed the problem in introducing a new keyword. Reusing
the old ones would seem confusing to me. As I said, I can already write
such a non-fallthrough-cond as a library facility. And other people have
written equivalent prototype libraries with explicit fall-through capabilities.
--
---
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: Wed, 20 Nov 2013 09:33:20 -0800 (PST)
Raw View
------=_Part_28_8079168.1384968800681
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 11:38:01 AM UTC+1, Ville Voutilainen wrote:
>
> > While the condval could be a context-sensetive keyword, I don't think
> cond
> > can be made into a full keyword (as it would need to be to introduce a
> > statement), it is already used as an identifier frequently, and would
> > invalidate old code.
>
> Yep. That is indeed the problem in introducing a new keyword. Reusing
> the old ones would seem confusing to me. As I said, I can already write
> such a non-fallthrough-cond as a library facility. And other people have
> written equivalent prototype libraries with explicit fall-through
> capabilities.
>
While the technical details of the differences between a normal switch and
the proposed explicit safe switch might seem a lot, they are in fact very
similar, and the goto case statement is a pure addition. For the most part
for everyday use people just need to know:
- append explicit as a specifier to your switch statements in new code.
- don't use implicit fallthrough, use goto case instead.
It's actually quite a small change, and I don't agree that it is confusing.
Your fear is that:
The subtler the difference is, the more likely it is that people
> accidentally
> write a "legacy" switch rather than the new one. And then we get back to
> square one, which is accidental bugs.
While I don't claim the proposal to be perfect, it is certainly better than
doing nothing, and I also think it is better than inventing a new alien
syntax just to be different. It is no different than explicit constructors
vs normal constructors, or static_cast vs C-style casts in this regard.
--
---
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_28_8079168.1384968800681
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 11:38:01 AM UTC+1, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">> While th=
e condval could be a context-sensetive keyword, I don't think cond
<br>> can be made into a full keyword (as it would need to be to introdu=
ce a
<br>> statement), it is already used as an identifier frequently, and wo=
uld
<br>> invalidate old code.
<br>
<br>Yep. That is indeed the problem in introducing a new keyword. Reusing
<br>the old ones would seem confusing to me. As I said, I can already write
<br>such a non-fallthrough-cond as a library facility. And other people hav=
e
<br>written equivalent prototype libraries with explicit fall-through capab=
ilities.<br></blockquote><div><br></div><div>While the technical details of=
the differences between a normal switch and the proposed explicit safe swi=
tch might seem a lot, they are in fact very similar, and the goto case stat=
ement is a pure addition. For the most part for everyday use people j=
ust need to know:</div><div><br></div><div>- append explicit as a specifier=
to your switch statements in new code.</div><div>- don't use implicit fall=
through, use goto case instead.</div><div><br></div><div>It's actually quit=
e a small change, and I don't agree that it is confusing. Your fear i=
s that:</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, =
204, 204); border-left-style: solid; padding-left: 1ex;">The subtler the di=
fference is, the more likely it is that people accidentally <br>write =
a "legacy" switch rather than the new one. And then we get back to <br=
>square one, which is accidental bugs.</blockquote><div><br></div><div>Whil=
e I don't claim the proposal to be perfect, it is certainly better than doi=
ng nothing, and I also think it is better than inventing a new alien syntax=
just to be different. It is no different than explicit constructors =
vs normal constructors, or static_cast vs C-style casts in this regard.</di=
v><div><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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_28_8079168.1384968800681--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 11:31:40 -0800
Raw View
--001a11c31b4efead6d04eba0d6ce
Content-Type: text/plain; charset=ISO-8859-1
I for one don't think it is "certainly better" than doing nothing. The
proposed language feature doesn't allow you to express anything "new" in
the language that couldn't be expressed before. It means yet another
feature for beginners to learn and understand.
Every feature starts out with -100 points. Compilers already allow people
to stick in [fallthrough] annotations and turn on appropriate warnings if
they wish.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 9:33 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 11:38:01 AM UTC+1, Ville Voutilainen wrote:
>>
>> > While the condval could be a context-sensetive keyword, I don't think
>> cond
>> > can be made into a full keyword (as it would need to be to introduce a
>> > statement), it is already used as an identifier frequently, and would
>> > invalidate old code.
>>
>> Yep. That is indeed the problem in introducing a new keyword. Reusing
>> the old ones would seem confusing to me. As I said, I can already write
>> such a non-fallthrough-cond as a library facility. And other people have
>> written equivalent prototype libraries with explicit fall-through
>> capabilities.
>>
>
> While the technical details of the differences between a normal switch and
> the proposed explicit safe switch might seem a lot, they are in fact very
> similar, and the goto case statement is a pure addition. For the most part
> for everyday use people just need to know:
>
> - append explicit as a specifier to your switch statements in new code.
> - don't use implicit fallthrough, use goto case instead.
>
> It's actually quite a small change, and I don't agree that it is
> confusing. Your fear is that:
>
> The subtler the difference is, the more likely it is that people
>> accidentally
>> write a "legacy" switch rather than the new one. And then we get back to
>> square one, which is accidental bugs.
>
>
> While I don't claim the proposal to be perfect, it is certainly better
> than doing nothing, and I also think it is better than inventing a new
> alien syntax just to be different. It is no different than explicit
> constructors vs normal constructors, or static_cast vs C-style casts in
> this regard.
>
>
> --
>
> ---
> 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/.
--001a11c31b4efead6d04eba0d6ce
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I for one don't think it is "certainly bette=
r" than doing nothing. The proposed language feature doesn't allow=
you to express anything "new" in the language that couldn't =
be expressed before. It means yet another feature for beginners to learn an=
d understand.</div>
<div><br></div><div>Every feature starts out with -100 points. Compilers al=
ready allow people to stick in [fallthrough] annotations and turn on approp=
riate warnings if they wish.</div></div><div class=3D"gmail_extra"><br clea=
r=3D"all">
<div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 9:33 AM, Andrew =
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" ta=
rget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 11:38:01=
AM UTC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
> While the condval could be a context-sensetive keyword, I don't th=
ink cond
<br>> can be made into a full keyword (as it would need to be to introdu=
ce a
<br>> statement), it is already used as an identifier frequently, and wo=
uld
<br>> invalidate old code.
<br>
<br>Yep. That is indeed the problem in introducing a new keyword. Reusing
<br>the old ones would seem confusing to me. As I said, I can already write
<br>such a non-fallthrough-cond as a library facility. And other people hav=
e
<br>written equivalent prototype libraries with explicit fall-through capab=
ilities.<br></blockquote><div><br></div></div><div>While the technical deta=
ils of the differences between a normal switch and the proposed explicit sa=
fe switch might seem a lot, they are in fact very similar, and the goto cas=
e statement is a pure addition. =A0For the most part for everyday use peopl=
e just need to know:</div>
<div><br></div><div>- append explicit as a specifier to your switch stateme=
nts in new code.</div><div>- don't use implicit fallthrough, use goto c=
ase instead.</div><div><br></div><div>It's actually quite a small chang=
e, and I don't agree that it is confusing. =A0Your fear is that:</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">The subtler the difference is, the more lik=
ely it is that people accidentally=A0<br>
write a "legacy" switch rather than the new one. And then we get =
back to=A0<br>square one, which is accidental bugs.</blockquote><div><br></=
div><div>While I don't claim the proposal to be perfect, it is certainl=
y better than doing nothing, and I also think it is better than inventing a=
new alien syntax just to be different. =A0It is no different than explicit=
constructors vs normal constructors, or static_cast vs C-style casts in th=
is regard.</div>
<div><br></div><div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"=
>
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c31b4efead6d04eba0d6ce--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 11:52:12 -0800 (PST)
Raw View
------=_Part_262_27292508.1384977132343
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 8:31:40 PM UTC+1, Billy O'Neal wrote:
>
> The proposed language feature doesn't allow you to express anything "new"
> in the language that couldn't be expressed before. It means yet another
> feature for beginners to learn and understand.
>
That same silly argument can be made against static_cast and explicit
constructors.
Compilers already allow people to stick in [fallthrough] annotations and
> turn on appropriate warnings if they wish.
>
That doesn't work because 3% of existing switch statements use implicit
fallthrough as a feature, so you would have to go through and update all
the old code adding the annotation.
--
---
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_262_27292508.1384977132343
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 8:31:40 PM UTC+1, Billy O'=
Neal 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>The proposed language feature doesn't allow you to express anything "new=
" in the language that couldn't be expressed before. It means yet another f=
eature for beginners to learn and understand.</div></div></blockquote><div>=
</div><div>That same silly argument can be made against static_cast a=
nd explicit constructors.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div></div><div>Compilers already allow pe=
ople to stick in [fallthrough] annotations and turn on appropriate warnings=
if they wish.</div></div><div></div></blockquote><div><br></div><div>That =
doesn't work because 3% of existing switch statements use implicit fallthro=
ugh as a feature, so you would have to go through and update all the old co=
de adding the annotation.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_262_27292508.1384977132343--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 12:03:15 -0800
Raw View
--047d7b4724a2e5f0d404eba1475d
Content-Type: text/plain; charset=ISO-8859-1
With the proposed language feature, you *also* have to go and update all
your old code by adding annotations. And in that case, you're updating the
3% of switches that need it, not the 97% that don't.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 11:52 AM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 8:31:40 PM UTC+1, Billy O'Neal wrote:
>>
>> The proposed language feature doesn't allow you to express anything "new"
>> in the language that couldn't be expressed before. It means yet another
>> feature for beginners to learn and understand.
>>
>
> That same silly argument can be made against static_cast and explicit
> constructors.
>
> Compilers already allow people to stick in [fallthrough] annotations and
>> turn on appropriate warnings if they wish.
>>
>
> That doesn't work because 3% of existing switch statements use implicit
> fallthrough as a feature, so you would have to go through and update all
> the old code adding the annotation.
>
> --
>
> ---
> 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/.
--047d7b4724a2e5f0d404eba1475d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">With the proposed language feature, you *also* have to go =
and update all your old code by adding annotations. And in that case, you&#=
39;re updating the 3% of switches that need it, not the 97% that don't.=
</div>
<div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>Bil=
ly O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/" targe=
t=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http:/=
/stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stacko=
verflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 11:52 AM, Andrew=
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" t=
arget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 8:31:40 =
PM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>The proposed language feature doesn't allow you t=
o express anything "new" in the language that couldn't be exp=
ressed before. It means yet another feature for beginners to learn and unde=
rstand.</div>
</div></blockquote><div>=A0</div></div><div>That same silly argument can be=
made against static_cast and explicit constructors.</div><div class=3D"im"=
><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wi=
dth:1px;border-left-style:solid">
<div dir=3D"ltr"><div></div><div>Compilers already allow people to stick in=
[fallthrough] annotations and turn on appropriate warnings if they wish.</=
div></div><div></div></blockquote><div><br></div></div><div>That doesn'=
t work because 3% of existing switch statements use implicit fallthrough as=
a feature, so you would have to go through and update all the old code add=
ing the annotation.</div>
<div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b4724a2e5f0d404eba1475d--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 12:09:35 -0800 (PST)
Raw View
------=_Part_527_3844456.1384978175619
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 9:03:15 PM UTC+1, Billy O'Neal wrote:
>
> With the proposed language feature, you *also* have to go and update all
> your old code by adding annotations. And in that case, you're updating the
> 3% of switches that need it, not the 97% that don't.
>
No, you don't have to, you can leave the old code alone. The old switch
statement remains unchanged.
--
---
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_527_3844456.1384978175619
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 9:03:15 PM UTC+1, Billy O'=
Neal 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">Wi=
th the proposed language feature, you *also* have to go and update all your=
old code by adding annotations. And in that case, you're updating the 3% o=
f switches that need it, not the 97% that don't.</div>
<div></div></blockquote><div><br></div>No, you don't have to, you can leave=
the old code alone. The old switch statement remains unchanged.<div>=
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_527_3844456.1384978175619--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 12:14:12 -0800
Raw View
--089e01537e421332e704eba16fbb
Content-Type: text/plain; charset=ISO-8859-1
Ah, I see what you mean. Don't see any reason the switch couldn't opt-in to
the warning with an annotation just as a switch can opt-out in a specific
case like [fallthrough].
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 12:09 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 9:03:15 PM UTC+1, Billy O'Neal wrote:
>>
>> With the proposed language feature, you *also* have to go and update all
>> your old code by adding annotations. And in that case, you're updating the
>> 3% of switches that need it, not the 97% that don't.
>>
>
> No, you don't have to, you can leave the old code alone. The old switch
> statement remains unchanged.
>
> --
>
> ---
> 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/.
--089e01537e421332e704eba16fbb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ah, I see what you mean. Don't see any reason the swit=
ch couldn't opt-in to the warning with an annotation just as a switch c=
an opt-out in a specific case like [fallthrough].</div><div class=3D"gmail_=
extra">
<br clear=3D"all"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a =
href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https://github=
..com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/users/82=
320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/82320/bil=
ly-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 12:09 PM, Andrew=
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" t=
arget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 9:03:15 =
PM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">With the proposed language feature, you *also* have to go =
and update all your old code by adding annotations. And in that case, you&#=
39;re updating the 3% of switches that need it, not the 97% that don't.=
</div>
<div></div></blockquote><div><br></div></div>No, you don't have to, you=
can leave the old code alone. =A0The old switch statement remains unchange=
d.<div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01537e421332e704eba16fbb--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 12:20:42 -0800 (PST)
Raw View
------=_Part_3979_1584791.1384978842438
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 9:14:12 PM UTC+1, Billy O'Neal wrote:
>
> Ah, I see what you mean. Don't see any reason the switch couldn't opt-in
> to the warning with an annotation just as a switch can opt-out in a
> specific case like [fallthrough].
>
Well now you're pretty much on the same page as the proposal. The only
difference is the "opt-in attribute" is a keyword-specifier `explicit
switch`, and rather than the `[[fallthrough]]` attribute we have added the
more general `goto case x` statement like in BCPL and C#.
--
---
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_3979_1584791.1384978842438
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 9:14:12 PM UTC+1, Billy O'=
Neal 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">Ah=
, I see what you mean. Don't see any reason the switch couldn't opt-in to t=
he warning with an annotation just as a switch can opt-out in a specific ca=
se like [fallthrough].</div><div></div></blockquote><div> </div><div>W=
ell now you're pretty much on the same page as the proposal. The only=
difference is the "opt-in attribute" is a keyword-specifier `explicit swit=
ch`, and rather than the `[[fallthrough]]` attribute we have added the more=
general `goto case x` statement like in BCPL and C#.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3979_1584791.1384978842438--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 12:36:34 -0800
Raw View
--089e013d0db00d0d8604eba1bf12
Content-Type: text/plain; charset=ISO-8859-1
The difference is that one requires changes to the core language, and
allows nasty constructs like "goto case x" which I've seen abused over and
over again in C#. ("Goto label is bad, so I'll put it in a switch instead")
Annotations don't require any modifications to the core language and can be
implemented as compiler vendors see fit.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 12:20 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 9:14:12 PM UTC+1, Billy O'Neal wrote:
>>
>> Ah, I see what you mean. Don't see any reason the switch couldn't opt-in
>> to the warning with an annotation just as a switch can opt-out in a
>> specific case like [fallthrough].
>>
>
> Well now you're pretty much on the same page as the proposal. The only
> difference is the "opt-in attribute" is a keyword-specifier `explicit
> switch`, and rather than the `[[fallthrough]]` attribute we have added the
> more general `goto case x` statement like in BCPL and C#.
>
> --
>
> ---
> 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/.
--089e013d0db00d0d8604eba1bf12
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>The difference is that one requires changes to the co=
re language, and allows nasty constructs like "goto case x" which=
I've seen abused over and over again in C#. ("Goto label is bad, =
so I'll put it in a switch instead")</div>
<div><br></div><div>Annotations don't require any modifications to the =
core language and can be implemented as compiler vendors see fit.</div></di=
v><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div>B=
illy O'Neal</div>
<div><a href=3D"https://bitbucket.org/BillyONeal/" target=3D"_blank">https:=
//github.com/BillyONeal/</a></div><div><a href=3D"http://stackoverflow.com/=
users/82320/billy-oneal" target=3D"_blank">http://stackoverflow.com/users/8=
2320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 12:20 PM, Andrew=
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" t=
arget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 9:14:12 =
PM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr">Ah, I see what you mean. Don't see any reason the swit=
ch couldn't opt-in to the warning with an annotation just as a switch c=
an opt-out in a specific case like [fallthrough].</div><div></div></blockqu=
ote>
<div>=A0</div></div><div>Well now you're pretty much on the same page a=
s the proposal. =A0The only difference is the "opt-in attribute" =
is a keyword-specifier `explicit switch`, and rather than the `[[fallthroug=
h]]` attribute we have added the more general `goto case x` statement like =
in BCPL and C#.</div>
<div><br></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013d0db00d0d8604eba1bf12--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 13:06:17 -0800 (PST)
Raw View
------=_Part_753_24844511.1384981578088
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 9:36:34 PM UTC+1, Billy O'Neal wrote:
>
> allows nasty constructs like "goto case x" which I've seen abused over and
> over again in C#. ("Goto label is bad, so I'll put it in a switch instead")
>
From a structured programming point-of-view they are not nasty, no. They
are exactly the same as a state machine or corountine design pattern. It's
no different than something like:
int state = 0;
while (true) switch (state)
{
case 0:
...
state = 3;
continue;
case 1:
...
state = x;
continue;
case ...:
...
and so on
}
which as you can see can be implemented currently without using goto
statements and labels. goto case statements provide no more power than
this. It is just like using continue in a loop.
Annotations don't require any modifications to the core language and can be
> implemented as compiler vendors see fit.
>
That's true, but this should be a core language feature. We shouldn't
think about what's "easier" to get passed the committee - we should do
what's best for the language.
--
---
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_753_24844511.1384981578088
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 9:36:34 PM UTC+1, Billy O'=
Neal 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>allows nasty constructs like "goto case x" which I've seen abused over a=
nd over again in C#. ("Goto label is bad, so I'll put it in a switch instea=
d")</div></div></blockquote><div> </div><div><div>From a structured pr=
ogramming point-of-view they are not nasty, no. They are exactly the =
same as a state machine or corountine design pattern. It's no differe=
nt than something like:</div></div><div><br></div><div> int st=
ate =3D 0;</div><div><br></div><div> while (true) switch (stat=
e)</div><div> {</div><div> case 0:</div><div>&nbs=
p; ...</div><div> state =3D=
3;</div><div> continue;</div><div> =
case 1:</div><div> ...</div><div> =
state =3D x;</div><div> continue;<=
/div><div> case ...:</div><div> ...=
</div><div> and so on</div><div> }<=
/div><div><br></div><div>which as you can see can be implemented currently =
without using goto statements and labels. goto case statements provid=
e no more power than this. It is just like using continue in a loop.<=
/div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>Annotations don't require any modifications to the core langu=
age and can be implemented as compiler vendors see fit.</div></div><div></d=
iv></blockquote><div><br></div><div>That's true, but this should be a core =
language feature. We shouldn't think about what's "easier" to get pas=
sed the committee - we should do what's best for the language.</div><div><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_753_24844511.1384981578088--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 13:11:12 -0800
Raw View
--089e013cba50f91a9904eba23a1c
Content-Type: text/plain; charset=ISO-8859-1
What's best for the language is not a new core language feature. If this
can be solved adequately using annotations which anyone can already
implement, this means that this is not a topic which needs to be drilled
into beginners learning the language, which is good for the language.
Having to explain yet another type of conditional is not an improvement.
> goto case statements provide no more power than this. It is just like
using continue in a loop.
Neither does "goto label", yet people complain about it constantly. Also,
saying "well, there are already ways to abuse the existing language" is not
justification for "let's add even more ways to abuse the language".
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 1:06 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 9:36:34 PM UTC+1, Billy O'Neal wrote:
>>
>> allows nasty constructs like "goto case x" which I've seen abused over
>> and over again in C#. ("Goto label is bad, so I'll put it in a switch
>> instead")
>>
>
> From a structured programming point-of-view they are not nasty, no. They
> are exactly the same as a state machine or corountine design pattern. It's
> no different than something like:
>
> int state = 0;
>
> while (true) switch (state)
> {
> case 0:
> ...
> state = 3;
> continue;
> case 1:
> ...
> state = x;
> continue;
> case ...:
> ...
> and so on
> }
>
> which as you can see can be implemented currently without using goto
> statements and labels. goto case statements provide no more power than
> this. It is just like using continue in a loop.
>
> Annotations don't require any modifications to the core language and can
>> be implemented as compiler vendors see fit.
>>
>
> That's true, but this should be a core language feature. We shouldn't
> think about what's "easier" to get passed the committee - we should do
> what's best for the language.
>
> --
>
> ---
> 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/.
--089e013cba50f91a9904eba23a1c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>What's best for the language is not a new core la=
nguage feature. If this can be solved adequately using annotations which an=
yone can already implement, this means that this is not a topic which needs=
to be drilled into beginners learning the language, which is good for the =
language. Having to explain yet another type of conditional is not an impro=
vement.</div>
<div><br></div><div>>=A0goto case statements provide no more power than =
this. =A0It is just like using continue in a loop.</div><div><br></div><div=
>Neither does "goto label", yet people complain about it constant=
ly. Also, saying "well, there are already ways to abuse the existing l=
anguage" is not justification for "let's add even more ways t=
o abuse the language".</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 1:06 PM, Andrew =
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" ta=
rget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 9:36:34 =
PM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>allows nasty constructs like "goto case x" =
which I've seen abused over and over again in C#. ("Goto label is =
bad, so I'll put it in a switch instead")</div></div></blockquote>
<div>=A0</div></div><div><div>From a structured programming point-of-view t=
hey are not nasty, no. =A0They are exactly the same as a state machine or c=
orountine design pattern. =A0It's no different than something like:</di=
v>
</div><div><br></div><div>=A0 =A0 int state =3D 0;</div><div><br></div><div=
>=A0 =A0 while (true) switch (state)</div><div>=A0 =A0 {</div><div>=A0 =A0 =
case 0:</div><div>=A0 =A0 =A0 =A0 ...</div><div>=A0 =A0 =A0 =A0 state =3D 3=
;</div><div>=A0 =A0 =A0 =A0 continue;</div>
<div>=A0 =A0 case 1:</div><div>=A0 =A0 =A0 =A0 ...</div><div>=A0 =A0 =A0 =
=A0 state =3D x;</div><div>=A0 =A0 =A0 =A0 continue;</div><div>=A0 =A0 case=
...:</div><div>=A0 =A0 =A0 =A0 ...</div><div>=A0 =A0 =A0 =A0 and so on</di=
v><div>=A0 =A0 }</div><div><br></div><div>which as you can see can be imple=
mented currently without using goto statements and labels. =A0goto case sta=
tements provide no more power than this. =A0It is just like using continue =
in a loop.</div>
<div class=3D"im"><div><br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,20=
4);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr"><div>Ann=
otations don't require any modifications to the core language and can b=
e implemented as compiler vendors see fit.</div>
</div><div></div></blockquote><div><br></div></div><div>That's true, bu=
t this should be a core language feature. =A0We shouldn't think about w=
hat's "easier" to get passed the committee - we should do wha=
t's best for the language.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-wid=
th:1px;border-left-style:solid">
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013cba50f91a9904eba23a1c--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 13:31:24 -0800 (PST)
Raw View
------=_Part_632_29267172.1384983084494
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 10:11:12 PM UTC+1, Billy O'Neal wrote:
>
> > goto case statements provide no more power than this. It is just like
> using continue in a loop.
>
> Neither does "goto label", yet people complain about it constantly.
>
No, goto case and goto label are not the same. A label can be anywhere in
the function, and can be fallen-through. A goto case only has a
destination at the start of one of the blocks of the switch.
From a state machine view, each block of the switch is a state handler, and
the goto case changes the state.
From a coroutine view, each block of the switch is a coroutine, and the
goto case is a function call to the next one to be executed.
Also, saying "well, there are already ways to abuse the existing language"
> is not justification for "let's add even more ways to abuse the language".
>
I'll let your imaginary strawman that said that know.
--
---
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_632_29267172.1384983084494
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, November 20, 2013 10:11:12 PM UTC+1, Billy O=
'Neal wrote:<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>> goto case statements provide no more power than this. I=
t is just like using continue in a loop.<br></div></div></blockquote><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><div=
>Neither does "goto label", yet people complain about it constantly.</div><=
/div></blockquote><div> </div><div>No, goto case and goto label =
are not the same. A label can be anywhere in the function, and can be=
fallen-through. A goto case only has a destination at the start of o=
ne of the blocks of the switch.</div><div><br></div><div>From a state machi=
ne view, each block of the switch is a state handler, and the goto case cha=
nges the state.</div><div><br></div><div>From a coroutine view, each block =
of the switch is a coroutine, and the goto case is a function call to the n=
ext one to be executed.</div><div><br></div><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); border-left-style: solid; padding-left: 1ex=
;"><div dir=3D"ltr">Also, saying "well, there are already ways to abuse the=
existing language" is not justification for "let's add even more ways to a=
buse the language".</div></blockquote><div><br></div><div>I'll let your ima=
ginary strawman that said that know. </div></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_632_29267172.1384983084494--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 13:36:29 -0800
Raw View
--001a11332d165e96b404eba2950e
Content-Type: text/plain; charset=ISO-8859-1
>No, goto case and goto label are not the same. A label can be anywhere in
the function, and can be fallen-through. A goto case only has a
destination at the start of one of the blocks of the switch.
I don't see how that's much better than plain goto label.
>I'll let your imaginary strawman that said that know.
I don't see strawman in any argument made by either party as of yet. You
proposed new feature X, and I pointed out that it is extremely easy to
abuse that feature. I'm not refuting or arguing against anything other than
the proposed feature X. You made a separate statement, saying that indeed
feature Y already in the language already allows similar abuse. However,
that says nothing about proposed feature X.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 1:31 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 10:11:12 PM UTC+1, Billy O'Neal wrote:
>>
>> > goto case statements provide no more power than this. It is just like
>> using continue in a loop.
>>
>
>> Neither does "goto label", yet people complain about it constantly.
>>
>
> No, goto case and goto label are not the same. A label can be anywhere in
> the function, and can be fallen-through. A goto case only has a
> destination at the start of one of the blocks of the switch.
>
> From a state machine view, each block of the switch is a state handler,
> and the goto case changes the state.
>
> From a coroutine view, each block of the switch is a coroutine, and the
> goto case is a function call to the next one to be executed.
>
> Also, saying "well, there are already ways to abuse the existing language"
>> is not justification for "let's add even more ways to abuse the language".
>>
>
> I'll let your imaginary strawman that said that know.
>
> --
>
> ---
> 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/.
--001a11332d165e96b404eba2950e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>>No, goto case and goto label are not the same. =
=A0A label can be anywhere in the function, and can be fallen-through. =A0A=
goto case only has a destination at the start of one of the blocks of the =
switch.</div>
<div>I don't see how that's much better than plain goto label.</div=
><div><br></div><div>>I'll let your imaginary strawman that said tha=
t know.=A0</div><div>I don't see strawman in any argument made by eithe=
r party as of yet. You proposed new feature X, and I pointed out that it is=
extremely easy to abuse that feature. I'm not refuting or arguing agai=
nst anything other than the proposed feature X. You made a separate stateme=
nt, saying that indeed feature Y already in the language already allows sim=
ilar abuse. However, that says nothing about proposed feature X.</div>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 1:31 PM, Andrew =
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" ta=
rget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im">On Wednesday, November 20, 2013 10:11:12=
PM UTC+1, Billy O'Neal wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204=
,204);border-left-width:1px;border-left-style:solid">
<div dir=3D"ltr"><div>>=A0goto case statements provide no more power tha=
n this. =A0It is just like using continue in a loop.<br></div></div></block=
quote><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;p=
adding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;bo=
rder-left-style:solid">
<div dir=3D"ltr"><div><br></div><div>Neither does "goto label", y=
et people complain about it constantly.</div></div></blockquote><div>=A0=A0=
</div></div><div>No, goto case and goto label are not the same. =A0A label =
can be anywhere in the function, and can be fallen-through. =A0A goto case =
only has a destination at the start of one of the blocks of the switch.</di=
v>
<div><br></div><div>From a state machine view, each block of the switch is =
a state handler, and the goto case changes the state.</div><div><br></div><=
div>From a coroutine view, each block of the switch is a coroutine, and the=
goto case is a function call to the next one to be executed.</div>
<div><br></div><div><div class=3D"im"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,2=
04,204);border-left-width:1px;border-left-style:solid"><div dir=3D"ltr">Als=
o, saying "well, there are already ways to abuse the existing language=
" is not justification for "let's add even more ways to abuse=
the language".</div>
</blockquote><div><br></div></div><div>I'll let your imaginary strawman=
that said that know.=A0</div></div><div><br></div></div><div class=3D"HOEn=
Zb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11332d165e96b404eba2950e--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 20 Nov 2013 13:47:28 -0800 (PST)
Raw View
------=_Part_1394_6187135.1384984048924
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 20, 2013 10:36:29 PM UTC+1, Billy O'Neal wrote:
>
> >No, goto case and goto label are not the same. A label can be anywhere
> in the function, and can be fallen-through. A goto case only has a
> destination at the start of one of the blocks of the switch.
> I don't see how that's much better than plain goto label.
>
You said:
| allows nasty constructs like "goto case x" which I've seen abused over
and over again in C#.
Provide an example of one of these abusive uses of goto case that you have
seen.
--
---
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_1394_6187135.1384984048924
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><font color=3D"#000000">On Wednesday, November 20, 2013 10=
:36:29 PM UTC+1, Billy O'Neal wrote:</font><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><font color=3D"#000000">>No, goto cas=
e and goto label are not the same. A label can be anywhere in the fun=
ction, and can be fallen-through. A goto case only has a destination =
at the start of one of the blocks of the switch.</font></div>
<div><font color=3D"#000000">I don't see how that's much better than plain =
goto label.</font></div></div></blockquote><div><font color=3D"#000000"><br=
></font></div><div><font color=3D"#000000">You said:</font></div><div><font=
color=3D"#000000"><br></font></div><div><font color=3D"#000000">| allows n=
asty constructs like "goto case x" which I've seen abused over and over aga=
in in C#.<br></font></div><div><font color=3D"#000000"><br></font></div><di=
v><font color=3D"#000000">Provide an example of one of these abusive uses o=
f goto case that you have seen.</font></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1394_6187135.1384984048924--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 20 Nov 2013 14:50:23 -0800
Raw View
--089e0149ce369fb99d04eba39d0a
Content-Type: text/plain; charset=ISO-8859-1
Unfortunately I don't have examples of this on hand at the moment. Suffice
to say, any bad code you've seen a beginner write with "goto label", I've
seen beginners in C# try to mimic with "goto case".
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Wed, Nov 20, 2013 at 1:47 PM, Andrew Tomazos <andrewtomazos@gmail.com>wrote:
> On Wednesday, November 20, 2013 10:36:29 PM UTC+1, Billy O'Neal wrote:
>>
>> >No, goto case and goto label are not the same. A label can be anywhere
>> in the function, and can be fallen-through. A goto case only has a
>> destination at the start of one of the blocks of the switch.
>> I don't see how that's much better than plain goto label.
>>
>
> You said:
>
> | allows nasty constructs like "goto case x" which I've seen abused over
> and over again in C#.
>
> Provide an example of one of these abusive uses of goto case that you have
> seen.
>
> --
>
> ---
> 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/.
--089e0149ce369fb99d04eba39d0a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Unfortunately I don't have examples of this on ha=
nd at the moment. Suffice to say, any bad code you've seen a beginner w=
rite with "goto label", I've seen beginners in C# try to mimi=
c with "goto case".</div>
<div><br></div><div>Billy O'Neal</div><div class=3D"gmail_extra"><div><=
div dir=3D"ltr"><div><a href=3D"https://bitbucket.org/BillyONeal/" target=
=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"http://=
stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackov=
erflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Wed, Nov 20, 2013 at 1:47 PM, Andrew =
Tomazos <span dir=3D"ltr"><<a href=3D"mailto:andrewtomazos@gmail.com" ta=
rget=3D"_blank">andrewtomazos@gmail.com</a>></span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid">
<div dir=3D"ltr"><div class=3D"im"><font color=3D"#000000">On Wednesday, No=
vember 20, 2013 10:36:29 PM UTC+1, Billy O'Neal wrote:</font><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;=
border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:=
solid">
<div dir=3D"ltr"><div><font color=3D"#000000">>No, goto case and goto la=
bel are not the same. =A0A label can be anywhere in the function, and can b=
e fallen-through. =A0A goto case only has a destination at the start of one=
of the blocks of the switch.</font></div>
<div><font color=3D"#000000">I don't see how that's much better tha=
n plain goto label.</font></div></div></blockquote><div><font color=3D"#000=
000"><br></font></div></div><div class=3D"im"><div><font color=3D"#000000">=
You said:</font></div>
<div><font color=3D"#000000"><br></font></div><div><font color=3D"#000000">=
| allows nasty constructs like "goto case x" which I've seen =
abused over and over again in C#.<br></font></div><div><font color=3D"#0000=
00"><br>
</font></div></div><div><font color=3D"#000000">Provide an example of one o=
f these abusive uses of goto case that you have seen.</font></div><div><br>=
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0149ce369fb99d04eba39d0a--
.
Author: matthew.woehlke@kitware.com
Date: Mon, 30 Dec 2013 13:10:49 -0800 (PST)
Raw View
------=_Part_149_31860228.1388437849198
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, November 18, 2013 4:13:30 PM UTC-5, Andrew Tomazos wrote:
> Ok. At bare minimum I think everyone agrees we want implicit fallthrough=
=20
> ill-formed in a safe switch, and assuming that counts as a semantic effec=
t,=20
> then that rules out using an attribute.
>
=20
I was considering submitting a proposal to this effect. Given, per above,=
=20
doing Bad Thing with scope is already rejected by at least GCC and MSVC,=20
the main "issue" seems to be, as in the previous comment, that implicit=20
fall-through is bad.
To that, I would like to offer a counter proposal: newly allow the=20
'continue' keyword=B9 to be used inside 'switch'. The effect would be like=
=20
the discussed 'goto case <x>' where <x> is the next 'case' label to appear=
=20
in the current 'switch' scope. (I'd be further open to only allowing it=20
immediately preceding 'case <x>:'.) By default, implicit fallthrough is=20
unchanged, but having a standard mechanism for explicit fallthrough would=
=20
encourage compilers to supply an option to diagnose implitic fallthrough.=
=20
Programmers with conformant code could specify that the effect of this=20
diagnostic is a compiler error (i.e. -Werror, equivalent pragma, etc.).=20
Note that I am NOT proposing to generally allow branching to any case label=
..
This has a significant advantage over an attribute in that existing uses of=
=20
'switch' with no fallthrough don't need to be modified to gain protection,=
=20
and the overhead of protection is a compile flag. (Any case of intentional=
=20
fallthrough will incur overhead of being marked as such in some manner, so=
=20
can be discounted when comparing options.)
There seems to be some degree of consensus that the best solution is to=20
annotate intentional fallthrough, to which I strongly agree, but will add=
=20
that I see significant value in standardizing the mechanism for doing such.=
=20
Otherwise, practically speaking, we have to use=20
'<PROJECT>_SWITCH_FALLTHROUGH' which a: looks ugly and b: must be=20
conditionally defined for each compiler (e.g. '[[clang::fallthrough]]',=20
etc.) by every project that wants to use it.
(=B9 ...or at least a standardized attribute. I like the symmetry of=20
'continue' with 'break', but to some extent it is bikeshedding.)
--=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_149_31860228.1388437849198
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, November 18, 2013 4:13:30 PM UTC-5, Andrew Toma=
zos wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>Ok. At bare minimum I think everyone agrees we want implicit fa=
llthrough ill-formed in a safe switch, and assuming that counts as a semant=
ic effect, then that rules out using an attribute.</div></div></blockquote>=
<div> </div><div>I was considering submitting a proposal to this effec=
t. Given, per above, doing Bad Thing with scope is already rejected by at l=
east GCC and MSVC, the main "issue" seems to be, as in the previous comment=
, that implicit fall-through is bad.</div><div><br></div><div>To that, I wo=
uld like to offer a counter proposal: newly allow the 'continue' keyword=B9=
to be used inside 'switch'. The effect would be like the discussed 'goto c=
ase <x>' where <x> is the next 'case' label to appear in the cu=
rrent 'switch' scope. (I'd be further open to only allowing it immediately =
preceding 'case <x>:'.) By default, implicit fallthrough is unchanged=
, but having a standard mechanism for explicit fallthrough would encourage =
compilers to supply an option to diagnose implitic fallthrough. Programmers=
with conformant code could specify that the effect of this diagnostic is a=
compiler error (i.e. -Werror, equivalent pragma, etc.). Note that I am NOT=
proposing to generally allow branching to any case label.</div><div><br></=
div><div>This has a significant advantage over an attribute in that existin=
g uses of 'switch' with no fallthrough don't need to be modified to gain pr=
otection, and the overhead of protection is a compile flag. (Any case of in=
tentional fallthrough will incur overhead of being marked as such in some m=
anner, so can be discounted when comparing options.)</div><div><br></div><d=
iv>There seems to be some degree of consensus that the best solution is to =
annotate intentional fallthrough, to which I strongly agree, but will add t=
hat I see significant value in standardizing the mechanism for doing such. =
Otherwise, practically speaking, we have to use '<PROJECT>_SWITCH_FAL=
LTHROUGH' which a: looks ugly and b: must be conditionally defined for each=
compiler (e.g. '[[clang::fallthrough]]', etc.) by every project that wants=
to use it.</div><div><br></div><div>(=B9 ...or at least a standardized att=
ribute. I like the symmetry of 'continue' with 'break', but to some extent =
it is bikeshedding.)</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_149_31860228.1388437849198--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 30 Dec 2013 23:41:02 +0200
Raw View
On 30 December 2013 23:10, <matthew.woehlke@kitware.com> wrote:
> To that, I would like to offer a counter proposal: newly allow the
> 'continue' keyword=B9 to be used inside 'switch'. The effect would be lik=
e the
> discussed 'goto case <x>' where <x> is the next 'case' label to appear in
> the current 'switch' scope. (I'd be further open to only allowing it
Please show an example of what you mean exactly. Do you mean
'continue caselabel;', or plain 'continue;'? The latter _is_ allowed
in a switch,
and it continues any surrounding loop, so you need to differentiate this
new idea from existing code.
for (int i =3D 0; i < 3; ++i) {
switch (i) {
case 0:
case 2:
cout << "continuing, ";
continue;
case 1:
cout << "one!!1";
}
}
This will print
continuing, one!!1 continuing,
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 30 Dec 2013 17:05:22 -0500
Raw View
On 2013-12-30 16:41, Ville Voutilainen wrote:
> On 30 December 2013 23:10, <matthew.woehlke@kitware.com> wrote:
>> To that, I would like to offer a counter proposal: newly allow the
>> 'continue' keyword=B9 to be used inside 'switch'. The effect would be li=
ke the
>> discussed 'goto case <x>' where <x> is the next 'case' label to appear i=
n
>> the current 'switch' scope. (I'd be further open to only allowing it
>
> Please show an example of what you mean exactly. Do you mean
> 'continue caselabel;', or plain 'continue;'? The latter _is_ allowed
> in a switch,
> and it continues any surrounding loop, so you need to differentiate this
> new idea from existing code.
>
> for (int i =3D 0; i < 3; ++i) {
> switch (i) {
> case 0:
> case 2:
> cout << "continuing, ";
> continue;
> case 1:
> cout << "one!!1";
> }
> }
>
> This will print
> continuing, one!!1 continuing,
Right. I was forgetting when I wrote that about being enclosed in an=20
outer loop :-/. Which of course is related to the problem of not being=20
able to use 'break' within a 'switch' to exit an outer control loop.
One obvious solution is to instead standardize '[[fallthrough]]'.=20
Another possibility, that might have potential down the road, is to=20
allow 'continue switch;'. The use of the control structure keyword=20
following the flow control keyword indicates which control structure is=20
to be affected. This would conceptually allow us to write 'break for;'=20
within the 'switch' (e.g. in your above example) to break out of the=20
'for' loop. (Presumably this would extend to other contexts also, not=20
just 'switch'. How to specify 'the outer of two for loops' is left as an=20
exercise for another day, since this is beyond the topic at hand.)
I'd love to see 'continue <label>', as I do seem to recall wanting to be=20
able to jump about in a switch on at least one occasion, but I'd prefer=20
to see '[[fallthrough]]' than to continue not having a standard way to=20
express explicit fallthrough.
--=20
Matthew
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 31 Dec 2013 00:13:52 +0200
Raw View
On 31 December 2013 00:05, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2013-12-30 16:41, Ville Voutilainen wrote:
> One obvious solution is to instead standardize '[[fallthrough]]'. Another
> possibility, that might have potential down the road, is to allow 'continue
> switch;'. The use of the control structure keyword following the flow
> control keyword indicates which control structure is to be affected. This
> would conceptually allow us to write 'break for;' within the 'switch' (e.g.
> in your above example) to break out of the 'for' loop. (Presumably this
> would extend to other contexts also, not just 'switch'. How to specify 'the
> outer of two for loops' is left as an exercise for another day, since this
> is beyond the topic at hand.)
I have seen 'break for' and there was an idea floated around about
'break for for' that would break out of two for loops. I didn't hate it, but
I didn't love it either - I don't write code where it's an issue. I don't think
people expect it to work across functions.
I remain unconvinced that these fixes to switch are significantly good. In other
words, I think I'm still weakly opposed to every idea I've seen here.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Mon, 30 Dec 2013 14:32:42 -0800
Raw View
--001a1133056a1491da04eec80895
Content-Type: text/plain; charset=ISO-8859-1
The fix for "I can't break out of a loop in a switch" is to extract the
thing into a function and "break out of the switch" with "return".
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
Malware Response Instructor - BleepingComputer.com
On Mon, Dec 30, 2013 at 2:13 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 31 December 2013 00:05, Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
> > On 2013-12-30 16:41, Ville Voutilainen wrote:
> > One obvious solution is to instead standardize '[[fallthrough]]'. Another
> > possibility, that might have potential down the road, is to allow
> 'continue
> > switch;'. The use of the control structure keyword following the flow
> > control keyword indicates which control structure is to be affected. This
> > would conceptually allow us to write 'break for;' within the 'switch'
> (e.g.
> > in your above example) to break out of the 'for' loop. (Presumably this
> > would extend to other contexts also, not just 'switch'. How to specify
> 'the
> > outer of two for loops' is left as an exercise for another day, since
> this
> > is beyond the topic at hand.)
>
> I have seen 'break for' and there was an idea floated around about
> 'break for for' that would break out of two for loops. I didn't hate it,
> but
> I didn't love it either - I don't write code where it's an issue. I don't
> think
> people expect it to work across functions.
>
> I remain unconvinced that these fixes to switch are significantly good. In
> other
> words, I think I'm still weakly opposed to every idea I've seen here.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> 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/.
--001a1133056a1491da04eec80895
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The fix for "I can't break out of a loop in a swi=
tch" is to extract the thing into a function and "break out of th=
e switch" with "return".</div><div class=3D"gmail_extra"><br=
clear=3D"all">
<div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"https://bi=
tbucket.org/BillyONeal/" target=3D"_blank">https://github.com/BillyONeal/</=
a></div><div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" t=
arget=3D"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
<div>Malware Response Instructor - BleepingComputer.com</div></div></div>
<br><br><div class=3D"gmail_quote">On Mon, Dec 30, 2013 at 2:13 PM, Ville V=
outilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.=
com" target=3D"_blank">ville.voutilainen@gmail.com</a>></span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div class=3D"im">On 31 December 2013 00:05, Matthew Woehlke <<a href=3D=
"mailto:mwoehlke.floss@gmail.com">mwoehlke.floss@gmail.com</a>> wrote:<b=
r>
> On 2013-12-30 16:41, Ville Voutilainen wrote:<br>
</div><div class=3D"im">> One obvious solution is to instead standardize=
'[[fallthrough]]'. Another<br>
> possibility, that might have potential down the road, is to allow '=
;continue<br>
> switch;'. The use of the control structure keyword following the f=
low<br>
> control keyword indicates which control structure is to be affected. T=
his<br>
> would conceptually allow us to write 'break for;' within the &=
#39;switch' (e.g.<br>
> in your above example) to break out of the 'for' loop. (Presum=
ably this<br>
> would extend to other contexts also, not just 'switch'. How to=
specify 'the<br>
> outer of two for loops' is left as an exercise for another day, si=
nce this<br>
> is beyond the topic at hand.)<br>
<br>
</div>I have seen 'break for' and there was an idea floated around =
about<br>
'break for for' that would break out of two for loops. I didn't=
hate it, but<br>
I didn't love it either - I don't write code where it's an issu=
e. I don't think<br>
people expect it to work across functions.<br>
<br>
I remain unconvinced that these fixes to switch are significantly good. In =
other<br>
words, I think I'm still weakly opposed to every idea I've seen her=
e.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1133056a1491da04eec80895--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 31 Dec 2013 00:40:56 +0200
Raw View
On 31 December 2013 00:32, Billy O'Neal <billy.oneal@gmail.com> wrote:
> The fix for "I can't break out of a loop in a switch" is to extract the
> thing into a function and "break out of the switch" with "return".
I can break out of a loop just fine, using goto.
--
---
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: Tue, 31 Dec 2013 00:47:40 +0200
Raw View
On 31 December 2013 00:40, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 31 December 2013 00:32, Billy O'Neal <billy.oneal@gmail.com> wrote:
>> The fix for "I can't break out of a loop in a switch" is to extract the
>> thing into a function and "break out of the switch" with "return".
>
>
> I can break out of a loop just fine, using goto.
I can also break out of loops with break, since it doesn't do funny
things inside
an if-else, so to each their own, and to users of switch, pox on all
of your houses. :)
--
---
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: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Mon, 30 Dec 2013 18:09:13 -0500
Raw View
On 2013-12-30 17:13, Ville Voutilainen wrote:
> On 31 December 2013 00:05, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> On 2013-12-30 16:41, Ville Voutilainen wrote:
>> One obvious solution is to instead standardize '[[fallthrough]]'. Another
>> possibility, that might have potential down the road, is to allow 'continue
>> switch;'. The use of the control structure keyword following the flow
>> control keyword indicates which control structure is to be affected. This
>> would conceptually allow us to write 'break for;' within the 'switch' (e.g.
>> in your above example) to break out of the 'for' loop. (Presumably this
>> would extend to other contexts also, not just 'switch'. How to specify 'the
>> outer of two for loops' is left as an exercise for another day, since this
>> is beyond the topic at hand.)
>
> I have seen 'break for' and there was an idea floated around about
> 'break for for' that would break out of two for loops. I didn't hate it, but
> I didn't love it either - I don't write code where it's an issue. I don't think
> people expect it to work across functions.
>
> I remain unconvinced that these fixes to switch are significantly good. In other
> words, I think I'm still weakly opposed to every idea I've seen here.
Accidental fallthrough is bad. There exists no standardized way to
denote intentional fallthrough. Therefore compilers cannot implement
diagnostics for this condition using standard constructs.
As far as I am concerned, this is the only important problem here, which
I would like to see resolved (in '14, if possible).
I fail to see significant harm in standardizing a mechanism to denote
intentional fallthrough, especially if done in a way that non-conforming
compilers can still compile conforming code.
AFAICT, standardizing '[[fallthrough]]' would accomplish that. As an
attribute, it can't(?) break existing code, and compilers that don't
support it will just ignore it. It has no effect on code generation.
Conforming compilers are required only to /omit/ a diagnostic when
fallthrough occurs if it has been so annotated as intentional, which
only affects compilers that have such a diagnostic in the first place
(and if they do, they likely already have a similar mechanism in place;
e.g. clang definitely does). In some ways, the only "real" effect on the
standard is to reserve the attribute "fallthrough" in the context of
"switch".
This resolves the problem in an opt-in fashion by allowing programmers
to request the diagnostic and to annotate intentional fallthrough in a
standardized manner.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 31 Dec 2013 01:17:25 +0200
Raw View
On 31 December 2013 01:09, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> Accidental fallthrough is bad. There exists no standardized way to denote
> intentional fallthrough. Therefore compilers cannot implement diagnostics
> for this condition using standard constructs.
>
> As far as I am concerned, this is the only important problem here, which I
> would like to see resolved (in '14, if possible).
14 is closed for features, no go there, Evolution will disregard such a proposal
as too late and Core won't even listen to discussions remotely related to it.
> AFAICT, standardizing '[[fallthrough]]' would accomplish that. As an
> attribute, it can't(?) break existing code, and compilers that don't support
> it will just ignore it. It has no effect on code generation. Conforming
> compilers are required only to /omit/ a diagnostic when fallthrough occurs
> if it has been so annotated as intentional, which only affects compilers
> that have such a diagnostic in the first place (and if they do, they likely
> already have a similar mechanism in place; e.g. clang definitely does). In
> some ways, the only "real" effect on the standard is to reserve the
> attribute "fallthrough" in the context of "switch".
I'd like to point out that currently the standard doesn't forbid implementations
to diagnose whatever they please. That's really neither here nor there, but
just for your information.
> This resolves the problem in an opt-in fashion by allowing programmers to
> request the diagnostic and to annotate intentional fallthrough in a
> standardized manner.
Yeah, I'm not hugely opposed to an attribute. Why not, fine. I hope they can
appertain to labels, though, so that this doesn't require grammar surgery.
--
---
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: Tue, 31 Dec 2013 02:05:34 -0800 (PST)
Raw View
------=_Part_1863_1878227.1388484334857
Content-Type: text/plain; charset=ISO-8859-1
Thanks for your feedback guys.
My current design has "explicit switch" substituted for "safe_switch" and
the new jump statements:
goto case <expr>
goto switch
Note that <expr> is not required to be a constant expression, but if it is
constant than there is required to be a case with that value. The
non-constant version could be caught by default or fall off the end if
there is no default.
goto switch jumps to the smallest enclosing switch statement. It is just
like goto label for some invented label that is just before the switch
statement. The benefit is in not polluting the function scope with a
manufactured label for this common and often-requested use case.
Explicit switches still include the separate scopes for case-statements.
The separate scopes allow for:
explicit switch (expr)
{
case 1:
T val = ...;
...
case 2:
T val = ...; // ok
...
}
which comes up a lot and doesn't require the annoying need to surround the
case-statements in a compound statement. It's not as dire as the implicit
fallthrough bug, but still worth addressing while we are here.
I've also got a design for a spec that has implicit fallthrough ill-formed
(really ill-formed) in an explicit switch. I was going to chat to the
undefined behaviour group about it to see if we also want to use in falling
off the end of a value-returning function.
Here is a rough sketch of the wording: In an explicit switch the
implementation must analyze each but the last case-statement with some
algorithm X that returns either true or false for each case-statement. X
must have the following properties: If it would be possible, if not for
this rule, to flow off the end of an input case statement, X must return
true. If the final sub-statement of the case statement is a jump statement
or a throw expression, X must return false. The return value of X in other
cases is unspecified. If X returns true for any case-statement the program
is ill-formed. [Note: As a quality of implementation issue X should attempt
to return false in as many of the unspecified cases as reasonably possible.]
With such a spec implicit fallthrough is guaranteed impossible in an
explicit switch.
I've ruled out proposing attributes. While it is arguable whether they
would be allowed for a given spec (I think not for the above), even if they
were allowed you don't want such common issues addressed with them anyway.
Aesthetically noone wants to read or write double-square-bracketed stuff
frequently occurring in all code, as it would do if we implemented explicit
switch with one.
Enjoy,
Andrew.
On Tuesday, December 31, 2013 12:17:25 AM UTC+1, Ville Voutilainen wrote:
>
> On 31 December 2013 01:09, Matthew Woehlke <mwoehlk...@gmail.com<javascript:>>
> wrote:
> > Accidental fallthrough is bad. There exists no standardized way to
> denote
> > intentional fallthrough. Therefore compilers cannot implement
> diagnostics
> > for this condition using standard constructs.
> >
> > As far as I am concerned, this is the only important problem here, which
> I
> > would like to see resolved (in '14, if possible).
>
> 14 is closed for features, no go there, Evolution will disregard such a
> proposal
> as too late and Core won't even listen to discussions remotely related to
> it.
>
> > AFAICT, standardizing '[[fallthrough]]' would accomplish that. As an
> > attribute, it can't(?) break existing code, and compilers that don't
> support
> > it will just ignore it. It has no effect on code generation. Conforming
> > compilers are required only to /omit/ a diagnostic when fallthrough
> occurs
> > if it has been so annotated as intentional, which only affects compilers
> > that have such a diagnostic in the first place (and if they do, they
> likely
> > already have a similar mechanism in place; e.g. clang definitely does).
> In
> > some ways, the only "real" effect on the standard is to reserve the
> > attribute "fallthrough" in the context of "switch".
>
> I'd like to point out that currently the standard doesn't forbid
> implementations
> to diagnose whatever they please. That's really neither here nor there,
> but
> just for your information.
>
> > This resolves the problem in an opt-in fashion by allowing programmers
> to
> > request the diagnostic and to annotate intentional fallthrough in a
> > standardized manner.
>
>
> Yeah, I'm not hugely opposed to an attribute. Why not, fine. I hope they
> can
> appertain to labels, though, so that this doesn't require grammar surgery.
>
--
---
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_1863_1878227.1388484334857
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Thanks for your feedback guys.</div><div><br></div>My=
current design has "explicit switch" substituted for "safe_switch" and the=
new jump statements:<div><br></div><div> goto case <expr&g=
t;</div><div> goto switch</div><div><br></div><div>Note that &=
lt;expr> is not required to be a constant expression, but if it is const=
ant than there is required to be a case with that value. The non-cons=
tant version could be caught by default or fall off the end if there is no =
default.</div><div><br></div><div>goto switch jumps to the smallest enclosi=
ng switch statement. It is just like goto label for some invented lab=
el that is just before the switch statement. The benefit is in not po=
lluting the function scope with a manufactured label for this common and of=
ten-requested use case.</div><div><br></div><div>Explicit switches still in=
clude the separate scopes for case-statements. The separate scopes al=
low for:<br></div><div><br></div><div> explicit switch (expr)<=
/div><div> {</div><div> case 1:</div><div> =
T val =3D ...;</div><div> &n=
bsp; ...</div><div><br></div><div> case 2:</div><div>&nb=
sp; T val =3D ...; // ok</div><div> =
...</div><div> }</div><div><br></di=
v><div>which comes up a lot and doesn't require the annoying need to surrou=
nd the case-statements in a compound statement. It's not as dire as t=
he implicit fallthrough bug, but still worth addressing while we are here.<=
/div><div><br></div><div>I've also got a design for a spec that has implici=
t fallthrough ill-formed (really ill-formed) in an explicit switch. I=
was going to chat to the undefined behaviour group about it to see if we a=
lso want to use in falling off the end of a value-returning function.</div>=
<div><br></div><div>Here is a rough sketch of the wording: In an expl=
icit switch the implementation must analyze each but the last case-statemen=
t with some algorithm X that returns either true or false for each case-sta=
tement. X must have the following properties: If it would be possible, if n=
ot for this rule, to flow off the end of an input case statement, X must re=
turn true. If the final sub-statement of the case statement is a jump=
statement or a throw expression, X must return false. The return val=
ue of X in other cases is unspecified. If X returns true for any case=
-statement the program is ill-formed. [Note: As a quality of implementation=
issue X should attempt to return false in as many of the unspecified cases=
as reasonably possible.]</div><div><br></div><div>With such a spec implici=
t fallthrough is guaranteed impossible in an explicit switch.</div><div><br=
></div><div>I've ruled out proposing attributes. While it is arguable=
whether they would be allowed for a given spec (I think not for the above)=
, even if they were allowed you don't want such common issues addressed wit=
h them anyway. Aesthetically noone wants to read or write double-squa=
re-bracketed stuff frequently occurring in all code, as it would do if we i=
mplemented explicit switch with one.</div><div><br></div><div>Enjoy,<br>&nb=
sp; Andrew.</div><div><br></div><div><br></div><div>On Tuesday, Decem=
ber 31, 2013 12:17:25 AM UTC+1, Ville Voutilainen wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">On 31 December 2013 01:09, Matthew Woehlke <=
<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"cQN1pKBX=
AU8J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"thi=
s.href=3D'javascript:';return true;">mwoehlk...@gmail.com</a>> wrote:
<br>> Accidental fallthrough is bad. There exists no standardized way to=
denote
<br>> intentional fallthrough. Therefore compilers cannot implement diag=
nostics
<br>> for this condition using standard constructs.
<br>>
<br>> As far as I am concerned, this is the only important problem here,=
which I
<br>> would like to see resolved (in '14, if possible).
<br>
<br>14 is closed for features, no go there, Evolution will disregard such a=
proposal
<br>as too late and Core won't even listen to discussions remotely related =
to it.
<br>
<br>> AFAICT, standardizing '[[fallthrough]]' would accomplish that. As =
an
<br>> attribute, it can't(?) break existing code, and compilers that don=
't support
<br>> it will just ignore it. It has no effect on code generation. Confo=
rming
<br>> compilers are required only to /omit/ a diagnostic when fallthroug=
h occurs
<br>> if it has been so annotated as intentional, which only affects com=
pilers
<br>> that have such a diagnostic in the first place (and if they do, th=
ey likely
<br>> already have a similar mechanism in place; e.g. clang definitely d=
oes). In
<br>> some ways, the only "real" effect on the standard is to reserve th=
e
<br>> attribute "fallthrough" in the context of "switch".
<br>
<br>I'd like to point out that currently the standard doesn't forbid implem=
entations
<br>to diagnose whatever they please. That's really neither here nor there,=
but
<br>just for your information.
<br>
<br>> This resolves the problem in an opt-in fashion by allowing program=
mers to
<br>> request the diagnostic and to annotate intentional fallthrough in =
a
<br>> standardized manner.
<br>
<br>
<br>Yeah, I'm not hugely opposed to an attribute. Why not, fine. I hope the=
y can
<br>appertain to labels, though, so that this doesn't require grammar surge=
ry.
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1863_1878227.1388484334857--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 1 Jan 2014 04:44:24 -0800 (PST)
Raw View
------=_Part_6978_3879773.1388580264638
Content-Type: text/plain; charset=ISO-8859-1
I like explicit switch better than safe_switch as it does not introduce new
keywords.
Could you explain what use case "goto switch" handles?
How would you write an explicit fallthrough? Do you mean that one has to
write goto case <next case label>? I think that it would be nice to be able
to not repeat the actual label. Of course "continue" would have been
perfect except for the clash with the loop use. Maybe "continue switch"
would work?
Den tisdagen den 31:e december 2013 kl. 11:05:34 UTC+1 skrev Andrew Tomazos:
>
> Thanks for your feedback guys.
>
> My current design has "explicit switch" substituted for "safe_switch" and
> the new jump statements:
>
> goto case <expr>
> goto switch
>
> Note that <expr> is not required to be a constant expression, but if it is
> constant than there is required to be a case with that value. The
> non-constant version could be caught by default or fall off the end if
> there is no default.
>
> goto switch jumps to the smallest enclosing switch statement. It is just
> like goto label for some invented label that is just before the switch
> statement. The benefit is in not polluting the function scope with a
> manufactured label for this common and often-requested use case.
>
> Explicit switches still include the separate scopes for case-statements.
> The separate scopes allow for:
>
> explicit switch (expr)
> {
> case 1:
> T val = ...;
> ...
>
> case 2:
> T val = ...; // ok
> ...
> }
>
> which comes up a lot and doesn't require the annoying need to surround the
> case-statements in a compound statement. It's not as dire as the implicit
> fallthrough bug, but still worth addressing while we are here.
>
> I've also got a design for a spec that has implicit fallthrough ill-formed
> (really ill-formed) in an explicit switch. I was going to chat to the
> undefined behaviour group about it to see if we also want to use in falling
> off the end of a value-returning function.
>
> Here is a rough sketch of the wording: In an explicit switch the
> implementation must analyze each but the last case-statement with some
> algorithm X that returns either true or false for each case-statement. X
> must have the following properties: If it would be possible, if not for
> this rule, to flow off the end of an input case statement, X must return
> true. If the final sub-statement of the case statement is a jump statement
> or a throw expression, X must return false. The return value of X in other
> cases is unspecified. If X returns true for any case-statement the program
> is ill-formed. [Note: As a quality of implementation issue X should attempt
> to return false in as many of the unspecified cases as reasonably possible.]
>
> With such a spec implicit fallthrough is guaranteed impossible in an
> explicit switch.
>
> I've ruled out proposing attributes. While it is arguable whether they
> would be allowed for a given spec (I think not for the above), even if they
> were allowed you don't want such common issues addressed with them anyway.
> Aesthetically noone wants to read or write double-square-bracketed stuff
> frequently occurring in all code, as it would do if we implemented explicit
> switch with one.
>
> Enjoy,
> Andrew.
>
>
> On Tuesday, December 31, 2013 12:17:25 AM UTC+1, Ville Voutilainen wrote:
>>
>> On 31 December 2013 01:09, Matthew Woehlke <mwoehlk...@gmail.com> wrote:
>> > Accidental fallthrough is bad. There exists no standardized way to
>> denote
>> > intentional fallthrough. Therefore compilers cannot implement
>> diagnostics
>> > for this condition using standard constructs.
>> >
>> > As far as I am concerned, this is the only important problem here,
>> which I
>> > would like to see resolved (in '14, if possible).
>>
>> 14 is closed for features, no go there, Evolution will disregard such a
>> proposal
>> as too late and Core won't even listen to discussions remotely related to
>> it.
>>
>> > AFAICT, standardizing '[[fallthrough]]' would accomplish that. As an
>> > attribute, it can't(?) break existing code, and compilers that don't
>> support
>> > it will just ignore it. It has no effect on code generation. Conforming
>> > compilers are required only to /omit/ a diagnostic when fallthrough
>> occurs
>> > if it has been so annotated as intentional, which only affects
>> compilers
>> > that have such a diagnostic in the first place (and if they do, they
>> likely
>> > already have a similar mechanism in place; e.g. clang definitely does).
>> In
>> > some ways, the only "real" effect on the standard is to reserve the
>> > attribute "fallthrough" in the context of "switch".
>>
>> I'd like to point out that currently the standard doesn't forbid
>> implementations
>> to diagnose whatever they please. That's really neither here nor there,
>> but
>> just for your information.
>>
>> > This resolves the problem in an opt-in fashion by allowing programmers
>> to
>> > request the diagnostic and to annotate intentional fallthrough in a
>> > standardized manner.
>>
>>
>> Yeah, I'm not hugely opposed to an attribute. Why not, fine. I hope they
>> can
>> appertain to labels, though, so that this doesn't require grammar
>> surgery.
>>
>
--
---
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_6978_3879773.1388580264638
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I like explicit switch better than safe_switch as it does =
not introduce new keywords.<div><br></div><div>Could you explain what use c=
ase "goto switch" handles?</div><div><br></div><div>How would you write an =
explicit fallthrough? Do you mean that one has to write goto case <next =
case label>? I think that it would be nice to be able to not repeat the =
actual label. Of course "continue" would have been perfect except for the c=
lash with the loop use. Maybe "continue switch" would work?</div><div><br><=
br>Den tisdagen den 31:e december 2013 kl. 11:05:34 UTC+1 skrev Andrew Toma=
zos:<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>Than=
ks for your feedback guys.</div><div><br></div>My current design has "expli=
cit switch" substituted for "safe_switch" and the new jump statements:<div>=
<br></div><div> goto case <expr></div><div> =
goto switch</div><div><br></div><div>Note that <expr> is not require=
d to be a constant expression, but if it is constant than there is required=
to be a case with that value. The non-constant version could be caug=
ht by default or fall off the end if there is no default.</div><div><br></d=
iv><div>goto switch jumps to the smallest enclosing switch statement.  =
;It is just like goto label for some invented label that is just before the=
switch statement. The benefit is in not polluting the function scope=
with a manufactured label for this common and often-requested use case.</d=
iv><div><br></div><div>Explicit switches still include the separate scopes =
for case-statements. The separate scopes allow for:<br></div><div><br=
></div><div> explicit switch (expr)</div><div> {<=
/div><div> case 1:</div><div>  =
;T val =3D ...;</div><div> ...</div><div><=
br></div><div> case 2:</div><div> &=
nbsp;T val =3D ...; // ok</div><div> ...</=
div><div> }</div><div><br></div><div>which comes up a lo=
t and doesn't require the annoying need to surround the case-statements in =
a compound statement. It's not as dire as the implicit fallthrough bu=
g, but still worth addressing while we are here.</div><div><br></div><div>I=
've also got a design for a spec that has implicit fallthrough ill-formed (=
really ill-formed) in an explicit switch. I was going to chat to the =
undefined behaviour group about it to see if we also want to use in falling=
off the end of a value-returning function.</div><div><br></div><div>Here i=
s a rough sketch of the wording: In an explicit switch the implementa=
tion must analyze each but the last case-statement with some algorithm X th=
at returns either true or false for each case-statement. X must have the fo=
llowing properties: If it would be possible, if not for this rule, to flow =
off the end of an input case statement, X must return true. If the fi=
nal sub-statement of the case statement is a jump statement or a throw expr=
ession, X must return false. The return value of X in other cases is =
unspecified. If X returns true for any case-statement the program is =
ill-formed. [Note: As a quality of implementation issue X should attempt to=
return false in as many of the unspecified cases as reasonably possible.]<=
/div><div><br></div><div>With such a spec implicit fallthrough is guarantee=
d impossible in an explicit switch.</div><div><br></div><div>I've ruled out=
proposing attributes. While it is arguable whether they would be all=
owed for a given spec (I think not for the above), even if they were allowe=
d you don't want such common issues addressed with them anyway. Aesth=
etically noone wants to read or write double-square-bracketed stuff frequen=
tly occurring in all code, as it would do if we implemented explicit switch=
with one.</div><div><br></div><div>Enjoy,<br> Andrew.</div><di=
v><br></div><div><br></div><div>On Tuesday, December 31, 2013 12:17:25 AM U=
TC+1, Ville Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 31=
December 2013 01:09, Matthew Woehlke <<a>mwoehlk...@gmail.com</a>> w=
rote:
<br>> Accidental fallthrough is bad. There exists no standardized way to=
denote
<br>> intentional fallthrough. Therefore compilers cannot implement diag=
nostics
<br>> for this condition using standard constructs.
<br>>
<br>> As far as I am concerned, this is the only important problem here,=
which I
<br>> would like to see resolved (in '14, if possible).
<br>
<br>14 is closed for features, no go there, Evolution will disregard such a=
proposal
<br>as too late and Core won't even listen to discussions remotely related =
to it.
<br>
<br>> AFAICT, standardizing '[[fallthrough]]' would accomplish that. As =
an
<br>> attribute, it can't(?) break existing code, and compilers that don=
't support
<br>> it will just ignore it. It has no effect on code generation. Confo=
rming
<br>> compilers are required only to /omit/ a diagnostic when fallthroug=
h occurs
<br>> if it has been so annotated as intentional, which only affects com=
pilers
<br>> that have such a diagnostic in the first place (and if they do, th=
ey likely
<br>> already have a similar mechanism in place; e.g. clang definitely d=
oes). In
<br>> some ways, the only "real" effect on the standard is to reserve th=
e
<br>> attribute "fallthrough" in the context of "switch".
<br>
<br>I'd like to point out that currently the standard doesn't forbid implem=
entations
<br>to diagnose whatever they please. That's really neither here nor there,=
but
<br>just for your information.
<br>
<br>> This resolves the problem in an opt-in fashion by allowing program=
mers to
<br>> request the diagnostic and to annotate intentional fallthrough in =
a
<br>> standardized manner.
<br>
<br>
<br>Yeah, I'm not hugely opposed to an attribute. Why not, fine. I hope the=
y can
<br>appertain to labels, though, so that this doesn't require grammar surge=
ry.
<br></blockquote></div></div></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6978_3879773.1388580264638--
.
Author: Chandler Carruth <chandlerc@gmail.com>
Date: Wed, 1 Jan 2014 22:20:14 -0500
Raw View
--001a113397cea7abde04eef44527
Content-Type: text/plain; charset=ISO-8859-1
Not to comment on this proposal, but to try to correct some misperceptions:
On Mon, Nov 18, 2013 at 7:01 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> My point in that answer is that
> 1. I see lots of people claim this jump table thing on switches.
> 2. I have never seen an actual program have a performance advantage by
> using a switch over an if/elseif ladder.
> 3. I have never seen an actual compiler generate the supposed "jump table"
> (though admittedly I don't make a habit of examining lots of assembly code).
>
Ok, I assure you modern compilers do build jump tables and that they are
important to performance. If you haven't spent a lot of time working with
compilers and looking at the generated machine code, don't make sweeping
claims (as in your previous post and the SO answer).
It is very easy to come up with a test case:
extern void a(), b(), c(), d(), e(), f(), g(), h();
void jump(int i) {
switch (i) {
case 0: return a();
case 1: return b();
case 2: return c();
case 3: return d();
case 4: return e();
case 5: return f();
case 6: return g();
case 7: return h();
}
}
Here is the output I see using top-of-tree Clang: http://paste2.org/xkIyWzx2
The "jmpq" instruction there is using a jump table.
If someone would show data describing an actual program compiled with
> a modern compiler where the choice of switch vs. if made a measurable
> performance difference, then I could be convinced otherwise.
>
This is actually much harder. =] As it happens, many modern optimizing
compilers can recognize the switch pattern when written as an if-chain, and
vice-versa. I would consider it a missed optimization in the compiler if
the way the source code represented the controlflow inhibited the
optimization.
That said, it is common when sitting down to compare A/B versions to
produce an if-chain which is not actually equivalent to the switch. It's
important to be careful to compare equivalent control flow.
Again with top-of-tree Clang, if I change the test case to the following, I
get the exact same generated code (including a jump table):
extern void a(), b(), c(), d(), e(), f(), g(), h();
void jump(int i) {
if (i == 0) return a();
if (i == 1) return b();
if (i == 2) return c();
if (i == 3) return d();
if (i == 4) return e();
if (i == 5) return f();
if (i == 6) return g();
if (i == 7) return h();
}
Modern compilers already do data-dependence analysis in order to enable
> features like auto-vectorization and auto-parallelization; and I find it
> hard to believe that such machinery couldn't be useful for proving
> switch-like characteristics about an if/elseif ladder.
>
While the machinery is useful, understand that not very many modern
compilers do auto-parallelization, and even their auto-vectorization is
very limited.
> Moreover, from the 10,000 foot view of what I've seen of e.g. LLVM IR,
> there's no way for the frontend to express that this is a switch statement
> to the optimizer,
>
http://llvm.org/docs/LangRef.html#switch-instruction
> so it must already be figuring this kind of stuff out implicitly. So...
> unless someone can show data showing otherwise, I remain unconvinced that
> the supposed "jump table" optimization which can be applied to a switch
> actually results in faster code on modern compilers.
>
Note that jump tables are not always faster. On x86, you'll notice Clang
and LLVM generating a chain of comparisons and branches if you only have 3
cases in my above example, but a jump table with the 8 cases I show. There
is a tradeoff here -- jump tables have a high constant-factor cost that has
to be offset by the number of comparisons that would be required without
the jump table.
>
> The argument we started with was "language construct X is unsafe, we
> should introduce a new construct, Y," my comment is merely "the language
> already has an alternative to X, and that alternative is Z". If / elseif
> already offers a complete solution to this problem:
> 1. It solves the cross variable scope issue.
> 2. Does not allow implicit fallthrough.
>
And I'll leave the rest of this thread to discuss the language feature. In
summary, my points are merely:
1) Modern compilers *do* form jump tables and they are very important to
performance.
2) Modern compilers *don't* need special syntax to do so, but a special
syntax sometimes helps programmers recognize and write such patterns.
Ultimately, design the language for the programmer, not the compiler.
--
---
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/.
--001a113397cea7abde04eef44527
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">Not to comment on this proposal=
, but to try to correct some misperceptions:</div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Mon, Nov 18, 2013 at 7:01 PM, Billy O&#=
39;Neal <span dir=3D"ltr"><<a href=3D"mailto:billy.oneal@gmail.com" targ=
et=3D"_blank" class=3D"cremed">billy.oneal@gmail.com</a>></span> wrote:<=
br>
<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>My point in that answer is that</div><div>1. I see lo=
ts of people claim this jump table thing on switches.</div>
<div>2. I have never seen an actual program have a performance advantage by=
using a switch over an if/elseif ladder.</div>
<div>3. I have never seen an actual compiler generate the supposed "ju=
mp table" (though admittedly I don't make a habit of examining lot=
s of assembly code).</div></blockquote><div><br></div><div>Ok, I assure you=
modern compilers do build jump tables and that they are important to perfo=
rmance. If you haven't spent a lot of time working with compilers and l=
ooking at the generated machine code, don't make sweeping claims (as in=
your previous post and the SO answer).</div>
<div><br></div><div>It is very easy to come up with a test case:</div><div>=
<br></div><div><div><font face=3D"courier new, monospace">extern void a(), =
b(), c(), d(), e(), f(), g(), h();</font></div><div><font face=3D"courier n=
ew, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">void jump(int i) {<=
/font></div><div><font face=3D"courier new, monospace">=A0 switch (i) {</fo=
nt></div><div><font face=3D"courier new, monospace">=A0 case 0: return a();=
</font></div>
<div><font face=3D"courier new, monospace">=A0 case 1: return b();</font></=
div><div><font face=3D"courier new, monospace">=A0 case 2: return c();</fon=
t></div><div><font face=3D"courier new, monospace">=A0 case 3: return d();<=
/font></div>
<div><font face=3D"courier new, monospace">=A0 case 4: return e();</font></=
div><div><font face=3D"courier new, monospace">=A0 case 5: return f();</fon=
t></div><div><font face=3D"courier new, monospace">=A0 case 6: return g();<=
/font></div>
<div><font face=3D"courier new, monospace">=A0 case 7: return h();</font></=
div><div><font face=3D"courier new, monospace">=A0 }</font></div><div><font=
face=3D"courier new, monospace">}</font></div></div><div><br></div><div>He=
re is the output I see using top-of-tree Clang: <a href=3D"http://paste2.or=
g/xkIyWzx2">http://paste2.org/xkIyWzx2</a></div>
<div>The "jmpq" instruction there is using a jump table.</div><di=
v><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);border-left-s=
tyle:solid;padding-left:1ex">
<div>If someone would show data describing an actual program compiled with =
a=A0modern compiler where the choice of switch vs. if made a measurable per=
formance difference, then I could be convinced otherwise.</div></blockquote=
>
<div><br></div><div>This is actually much harder. =3D] As it happens, many =
modern optimizing compilers can recognize the switch pattern when written a=
s an if-chain, and vice-versa. I would consider it a missed optimization in=
the compiler if the way the source code represented the controlflow inhibi=
ted the optimization.</div>
<div><br></div><div>That said, it is common when sitting down to compare A/=
B versions to produce an if-chain which is not actually equivalent to the s=
witch. It's important to be careful to compare equivalent control flow.=
</div>
<div><br></div><div>Again with top-of-tree Clang, if I change the test case=
to the following, I get the exact same generated code (including a jump ta=
ble):</div><div><div>extern void a(), b(), c(), d(), e(), f(), g(), h();</d=
iv>
<div><br></div><div>void jump(int i) {</div><div>=A0 if (i =3D=3D 0) return=
a();</div><div>=A0 if (i =3D=3D 1) return b();</div><div>=A0 if (i =3D=3D =
2) return c();</div><div>=A0 if (i =3D=3D 3) return d();</div><div>=A0 if (=
i =3D=3D 4) return e();</div>
<div>=A0 if (i =3D=3D 5) return f();</div><div>=A0 if (i =3D=3D 6) return g=
();</div><div>=A0 if (i =3D=3D 7) return h();</div><div>}</div></div><div><=
br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);b=
order-left-style:solid;padding-left:1ex">
<div> Modern compilers already do data-dependence analysis in order to enab=
le features like auto-vectorization and auto-parallelization; and I find it=
hard to believe that such machinery couldn't be useful for proving swi=
tch-like characteristics about an if/elseif ladder.</div>
</blockquote><div><br></div><div>While the machinery is useful, understand =
that not very many modern compilers do auto-parallelization, and even their=
auto-vectorization is very limited.</div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div> Moreover, from the 10,000 foot view of what I've seen of e.g. LLV=
M IR, there's no way for the frontend to express that this is a switch =
statement to the optimizer,</div></blockquote><div><br></div><div><a href=
=3D"http://llvm.org/docs/LangRef.html#switch-instruction">http://llvm.org/d=
ocs/LangRef.html#switch-instruction</a></div>
<div>=A0</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);border-left=
-style:solid;padding-left:1ex"><div> so it must already be figuring this ki=
nd of stuff out implicitly. So... unless someone can show data showing othe=
rwise, I remain unconvinced that the supposed "jump table" optimi=
zation which can be applied to a switch actually results in faster code on =
modern compilers.<br>
</div></blockquote><div><br></div><div>Note that jump tables are not always=
faster. On x86, you'll notice Clang and LLVM generating a chain of com=
parisons and branches if you only have 3 cases in my above example, but a j=
ump table with the 8 cases I show. There is a tradeoff here -- jump tables =
have a high constant-factor cost that has to be offset by the number of com=
parisons that would be required without the jump table.</div>
<div>=A0</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);border-left=
-style:solid;padding-left:1ex"><div></div>
<div><br></div><div>The argument we started with was "language constru=
ct X is unsafe, we should introduce a new construct, Y," my comment is=
merely "the language already has an alternative to X, and that altern=
ative is Z".=A0If / elseif already offers a complete solution to this =
problem:</div>
<div>1. It solves the cross variable scope issue.</div><div>2. Does not all=
ow implicit fallthrough.</div></blockquote></div><br>And I'll leave the=
rest of this thread to discuss the language feature. In summary, my points=
are merely:</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">1) Modern c=
ompilers *do* form jump tables and they are very important to performance.<=
/div><div class=3D"gmail_extra">2) Modern compilers *don't* need specia=
l syntax to do so, but a special syntax sometimes helps programmers recogni=
ze and write such patterns. Ultimately, design the language for the program=
mer, not the compiler.</div>
</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113397cea7abde04eef44527--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 1 Jan 2014 22:04:18 -0800 (PST)
Raw View
------=_Part_9272_23395937.1388642658962
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, January 2, 2014 4:20:14 AM UTC+1, Chandler Carruth wrote:
>
> Again with top-of-tree Clang, if I change the test case to the following,
> I get the exact same generated code (including a jump table):
> extern void a(), b(), c(), d(), e(), f(), g(), h();
>
> void jump(int i) {
> if (i == 0) return a();
> if (i == 1) return b();
> if (i == 2) return c();
> if (i == 3) return d();
> if (i == 4) return e();
> if (i == 5) return f();
> if (i == 6) return g();
> if (i == 7) return h();
> }
>
Almost true. Clang (not including LLVM) produces a LLVM `switch`
instruction for a C++ switch, and it produces an LLVM `br` chain for a C++
if-else chain. After Clang is finished the transformations inside LLVM
added by `-On` then spot the `br` chain and transform it into a LLVM
`switch` or visa versa. I think the llvm/lib/Transforms/Utils/LowerSwitch
turns LLVM switch instructions into br chains as a first step and then they
are rolled up back into switches if efficient by some other br chain to
switch transform in that directory. (But I guess you are lumping
Clang/LLVM together and calling it Clang, which is fine.)
On x86 a jump table is implemented with the scale index base addressing
form roughly like:
jmp [rax+8*rcx]
This is one 3 byte instruction. The address of the jump table is in rax
and the index of the jump table is in rcx. The 8 scale is for
sizeof(pointer).
Also of interest are the GCC extension "labels as values" and the goto
*expr statement:
http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
I agree with your overall analysis. Programmers chose to use switch
statements extensively, even given the option of if-else chains, as can be
demonstrated by the 1000s in clang/llvm source and almost any other C++
project. Of the top 10 languages on the planet only one (Perl) doesn't
have a switch statement and requires if-else chains instead, the rest all
have switch statements. The idea of deprecating switch statements in favor
of if-else chains was never given serious consideration. If for no other
reason than the semantic that the condition is evaluated once in a switch.
--
---
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_9272_23395937.1388642658962
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, January 2, 2014 4:20:14 AM UTC+1, Chandler Ca=
rruth wrote:<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>Again with top-of-tree Clang, if I change the test case to the followin=
g, I get the exact same generated code (including a jump table):<br></div><=
div><div class=3D"gmail_quote"><div><div>extern void a(), b(), c(), d(), e(=
), f(), g(), h();</div>
<div><br></div><div>void jump(int i) {</div><div> if (i =3D=3D 0) ret=
urn a();</div><div> if (i =3D=3D 1) return b();</div><div> if (=
i =3D=3D 2) return c();</div><div> if (i =3D=3D 3) return d();</div><=
div> if (i =3D=3D 4) return e();</div>
<div> if (i =3D=3D 5) return f();</div><div> if (i =3D=3D 6) re=
turn g();</div><div> if (i =3D=3D 7) return h();</div><div>}</div></d=
iv></div></div></div></blockquote><div> </div><div>Almost true. =
Clang (not including LLVM) produces a LLVM `switch` instruction for a C++ s=
witch, and it produces an LLVM `br` chain for a C++ if-else chain. Af=
ter Clang is finished the transformations inside LLVM added by `-On` then s=
pot the `br` chain and transform it into a LLVM `switch` or visa versa. &nb=
sp;I think the llvm/lib/Transforms/Utils/LowerSwitch turns LLVM switch inst=
ructions into br chains as a first step and then they are rolled up back in=
to switches if efficient by some other br chain to switch transform in that=
directory. (But I guess you are lumping Clang/LLVM together and call=
ing it Clang, which is fine.)</div><div><br></div><div>On x86 a jump table =
is implemented with the scale index base addressing form roughly like:</div=
><div><br></div><div> jmp [rax+8*rcx]</div><div><br></div><div>=
This is one 3 byte instruction. The address of the jump table is in r=
ax and the index of the jump table is in rcx. The 8 scale is for size=
of(pointer).</div><div><br></div><div>Also of interest are the GCC extensio=
n "labels as values" and the goto *expr statement:</div><div><br></div><div=
> http://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html<br><=
/div><div><br></div><div>I agree with your overall analysis. Programm=
ers chose to use switch statements extensively, even given the option of if=
-else chains, as can be demonstrated by the 1000s in clang/llvm source and =
almost any other C++ project. Of the top 10 languages on the planet o=
nly one (Perl) doesn't have a switch statement and requires if-else chains =
instead, the rest all have switch statements. The idea of deprecating=
switch statements in favor of if-else chains was never given serious consi=
deration. If for no other reason than the semantic that the condition=
is evaluated once in a switch.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_9272_23395937.1388642658962--
.
Author: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Wed, 1 Jan 2014 23:26:05 -0800
Raw View
--001a11334474397b2204eef7b7d0
Content-Type: text/plain; charset=ISO-8859-1
> Ok, I assure you modern compilers do build jump tables and that they are
important to performance. If you haven't spent a lot of time working with
compilers and looking at the generated machine code, don't make sweeping
claims (as in your previous post and the SO answer).
I don't see how I made any sweeping claim here. I said I had never seen a
compiler do this, which is true. I never claimed that there were no
conditions under which a compiler does.
Note that your example has a whole bunch of edge cases that make it
attractive to turn into a jump table:
1. There are a large number of branches in the switch
2. The branches form a contiguous run of consecutive numbers
3. The consecutive run of numbers includes 0
The argument I made here and in the StackOverflow answer is that I've seen
very few programs which meet this kind of criteria -- and that doing simple
binary search on the switch targets runs into no such generality problems.
I've encountered far too many programmers who think that the switch is
somehow magic, and is a constant time operation no matter how many branches
are in the switch or what values correspond to those branches.
> As it happens, many modern optimizing compilers can recognize the switch
pattern when written as an if-chain, and vice-versa.
Which was my point in the first place. Choosing switch over if/else for
"performance reasons" doesn't make sense.
> http://llvm.org/docs/LangRef.html#switch-instruction
Yes, someone else pointed this out ~a month ago. Learn something new every
day :)
Billy O'Neal
http://stackoverflow.com/users/82320/billy-oneal
--
---
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/.
--001a11334474397b2204eef7b7d0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=A0<span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">Ok, I assure you modern compilers do build jump tables and that th=
ey are important to performance. If you haven't spent a lot of time wor=
king with compilers and looking at the generated machine code, don't ma=
ke sweeping claims (as in your previous post and the SO answer).</span><div=
>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v><div><span style=3D"font-family:arial,sans-serif;font-size:13px">I don=
9;t see how I made any sweeping claim here. I said I had never seen a compi=
ler do this, which is true. I never claimed that there were no conditions u=
nder which a compiler does.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Not=
e that your example has a whole bunch of edge cases that make it attractive=
to turn into a jump table:</span></div>
<div><font face=3D"arial, sans-serif">1. There are a large number of branch=
es in the switch</font></div><div><font face=3D"arial, sans-serif">2. The b=
ranches form a contiguous run of consecutive numbers</font></div><div><font=
face=3D"arial, sans-serif">3. The consecutive run of numbers includes 0</f=
ont></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">The argument I made here and in the StackOverflow answer =
is that I've seen very few programs which meet this kind of criteria --=
and that doing simple binary search on the switch targets runs into no=A0s=
uch generality problems.</font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">I've encountered far too m=
any programmers who think that the switch is somehow magic, and is a consta=
nt time operation no matter how many branches are in the switch or what val=
ues correspond to those branches.</font></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">>=A0</font><span style=3D"font-family:arial,sans-serif=
;font-size:13px">As it happens, many modern optimizing compilers can recogn=
ize the switch pattern when written as an if-chain, and vice-versa.</span><=
span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</span></div>
<div><br></div><div><font face=3D"arial, sans-serif">Which was my point in =
the first place. Choosing switch over if/else for "performance reasons=
" doesn't make sense.</font></div><div><font face=3D"arial, sans-s=
erif"><br>
</font></div><div><font face=3D"arial, sans-serif">>=A0</font><a href=3D=
"http://llvm.org/docs/LangRef.html#switch-instruction" target=3D"_blank" st=
yle=3D"font-size:13px;font-family:arial,sans-serif">http://llvm.org/docs/La=
ngRef.html#switch-instruction</a></div>
<div><br></div><div>Yes, someone else pointed this out ~a month ago. Learn =
something new every day :)</div><div class=3D"gmail_extra"><br clear=3D"all=
"><div><div dir=3D"ltr"><div>Billy O'Neal</div><div><a href=3D"http://s=
tackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://stackove=
rflow.com/users/82320/billy-oneal</a></div>
</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11334474397b2204eef7b7d0--
.
Author: Troy Heron <troy.heron@hixxy.org>
Date: Thu, 2 Jan 2014 17:48:29 +1000
Raw View
--047d7bf0c922f6fae704eef804f5
Content-Type: text/plain; charset=ISO-8859-1
This also produces a jump table with clang:
extern void a(), b(), c(), d(), e(), f(), g(), h();
void jump(int i) {
switch (i) {
//case 0: return a();
case 1: return b();
case 2: return c();
//case 3: return d();
//case 4: return e();
case 5: return f();
// case 6: return g();
case 7: return h();
}
}
Notice the lack of starting at 0 or contiguousness of the case values?
On Thu, Jan 2, 2014 at 5:26 PM, Billy O'Neal <billy.oneal@gmail.com> wrote:
> > Ok, I assure you modern compilers do build jump tables and that they
> are important to performance. If you haven't spent a lot of time working
> with compilers and looking at the generated machine code, don't make
> sweeping claims (as in your previous post and the SO answer).
>
> I don't see how I made any sweeping claim here. I said I had never seen a
> compiler do this, which is true. I never claimed that there were no
> conditions under which a compiler does.
>
> Note that your example has a whole bunch of edge cases that make it
> attractive to turn into a jump table:
> 1. There are a large number of branches in the switch
> 2. The branches form a contiguous run of consecutive numbers
> 3. The consecutive run of numbers includes 0
>
> The argument I made here and in the StackOverflow answer is that I've seen
> very few programs which meet this kind of criteria -- and that doing simple
> binary search on the switch targets runs into no such generality problems.
>
> I've encountered far too many programmers who think that the switch is
> somehow magic, and is a constant time operation no matter how many branches
> are in the switch or what values correspond to those branches.
>
> > As it happens, many modern optimizing compilers can recognize the
> switch pattern when written as an if-chain, and vice-versa.
>
> Which was my point in the first place. Choosing switch over if/else for
> "performance reasons" doesn't make sense.
>
> > http://llvm.org/docs/LangRef.html#switch-instruction
>
> Yes, someone else pointed this out ~a month ago. Learn something new every
> day :)
>
> Billy O'Neal
> http://stackoverflow.com/users/82320/billy-oneal
>
> --
>
> ---
> 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/.
--047d7bf0c922f6fae704eef804f5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This also produces a jump table with clang:</div><div=
><br></div><div>extern void a(), b(), c(), d(), e(), f(), g(), h();</div><d=
iv><br></div><div>void jump(int i) {</div><div>=A0 switch (i) {</div><div>=
=A0 //case 0: return a();</div>
<div>=A0 case 1: return b();</div><div>=A0 case 2: return c();</div><div>=
=A0 //case 3: return d();</div><div>=A0 //case 4: return e();</div><div>=A0=
case 5: return f();</div><div>=A0// case 6: return g();</div><div>=A0 case=
7: return h();</div>
<div>=A0 }</div><div>}</div><div><br></div><div>Notice the lack of starting=
at 0 or contiguousness of the case values?</div><div><br></div></div><div =
class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Jan 2, 201=
4 at 5:26 PM, Billy O'Neal <span dir=3D"ltr"><<a href=3D"mailto:bill=
y.oneal@gmail.com" target=3D"_blank">billy.oneal@gmail.com</a>></span> w=
rote:<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"im">>=A0<s=
pan style=3D"font-family:arial,sans-serif;font-size:13px">Ok, I assure you =
modern compilers do build jump tables and that they are important to perfor=
mance. If you haven't spent a lot of time working with compilers and lo=
oking at the generated machine code, don't make sweeping claims (as in =
your previous post and the SO answer).</span><div>
<span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span></di=
v></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">I =
don't see how I made any sweeping claim here. I said I had never seen a=
compiler do this, which is true. I never claimed that there were no condit=
ions under which a compiler does.</span></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><span style=3D"font-family:arial,sans-serif;font-size:13px">Not=
e that your example has a whole bunch of edge cases that make it attractive=
to turn into a jump table:</span></div>
<div><font face=3D"arial, sans-serif">1. There are a large number of branch=
es in the switch</font></div><div><font face=3D"arial, sans-serif">2. The b=
ranches form a contiguous run of consecutive numbers</font></div><div><font=
face=3D"arial, sans-serif">3. The consecutive run of numbers includes 0</f=
ont></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">The argument I made here and in the StackOverflow answer =
is that I've seen very few programs which meet this kind of criteria --=
and that doing simple binary search on the switch targets runs into no=A0s=
uch generality problems.</font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div><div><font face=3D"arial, sans-serif">I've encountered far too m=
any programmers who think that the switch is somehow magic, and is a consta=
nt time operation no matter how many branches are in the switch or what val=
ues correspond to those branches.</font></div>
<div class=3D"im">
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">>=A0</font><span style=3D"font-family:arial,sans-serif=
;font-size:13px">As it happens, many modern optimizing compilers can recogn=
ize the switch pattern when written as an if-chain, and vice-versa.</span><=
span style=3D"font-family:arial,sans-serif;font-size:13px">=A0</span></div>
<div><br></div></div><div><font face=3D"arial, sans-serif">Which was my poi=
nt in the first place. Choosing switch over if/else for "performance r=
easons" doesn't make sense.</font></div><div><font face=3D"arial, =
sans-serif"><br>
</font></div><div><font face=3D"arial, sans-serif">>=A0</font><a href=3D=
"http://llvm.org/docs/LangRef.html#switch-instruction" style=3D"font-size:1=
3px;font-family:arial,sans-serif" target=3D"_blank">http://llvm.org/docs/La=
ngRef.html#switch-instruction</a></div>
<div><br></div><div>Yes, someone else pointed this out ~a month ago. Learn =
something new every day :)</div><span class=3D"HOEnZb"><font color=3D"#8888=
88"><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><div=
>Billy O'Neal</div>
<div><a href=3D"http://stackoverflow.com/users/82320/billy-oneal" target=3D=
"_blank">http://stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br></div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bf0c922f6fae704eef804f5--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 2 Jan 2014 11:20:28 +0200
Raw View
On 2 January 2014 05:20, Chandler Carruth <chandlerc@gmail.com> wrote:
> That said, it is common when sitting down to compare A/B versions to produce
> an if-chain which is not actually equivalent to the switch. It's important
> to be careful to compare equivalent control flow.
>
> Again with top-of-tree Clang, if I change the test case to the following, I
> get the exact same generated code (including a jump table):
> extern void a(), b(), c(), d(), e(), f(), g(), h();
>
> void jump(int i) {
> if (i == 0) return a();
> if (i == 1) return b();
> if (i == 2) return c();
> if (i == 3) return d();
> if (i == 4) return e();
> if (i == 5) return f();
> if (i == 6) return g();
> if (i == 7) return h();
> }
Just out of curiosity, what does your implementation do if that is
void jump(int i) {
if (i==0) return a();
else if (i==1) return b();
else if (i==2) return c();
...
}
--
---
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: dsanchez@cires21.com
Date: Thu, 2 Jan 2014 01:40:28 -0800 (PST)
Raw View
------=_Part_7159_28015337.1388655628820
Content-Type: text/plain; charset=ISO-8859-1
> Note that your example has a whole bunch of edge cases that make it
> attractive to turn into a jump table:
> 1. There are a large number of branches in the switch
> 2. The branches form a contiguous run of consecutive numbers
> 3. The consecutive run of numbers includes 0
>
> The argument I made here and in the StackOverflow answer is that I've seen
> very few programs which meet this kind of criteria -- and that doing simple
> binary search on the switch targets runs into no such generality problems.
>
I wouldn't think that switching on an enum is an edge case:
enum State
{
stopped,
paused,
running,
walking,
crawling
};
switch( state )
{
case stopped:
do something
break;
case paused:
do something
break;
case running:
do something
break;
case walking:
do something
break;
case crawling:
do something
break;
}
--
---
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_7159_28015337.1388655628820
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><span style=3D"font-family:arial,sans-serif;font-size:13px">N=
ote that your example has a whole bunch of edge cases that make it attracti=
ve to turn into a jump table:</span></div>
<div><font face=3D"arial, sans-serif">1. There are a large number of branch=
es in the switch</font></div><div><font face=3D"arial, sans-serif">2. The b=
ranches form a contiguous run of consecutive numbers</font></div><div><font=
face=3D"arial, sans-serif">3. The consecutive run of numbers includes 0</f=
ont></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">The argument I made here and in the StackOverflow answer =
is that I've seen very few programs which meet this kind of criteria -- and=
that doing simple binary search on the switch targets runs into no su=
ch generality problems.</font></div></div></blockquote><div><br></div><div>=
I wouldn't think that switching on an enum is an edge case:</div><div><br><=
/div><div style=3D"background-color: rgb(250, 250, 250); border: 1px solid =
rgb(187, 187, 187); word-wrap: break-word;" class=3D"prettyprint"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008=
;" class=3D"styled-by-prettify">enum</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">State</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
> stopped</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> paused</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> running</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> walking</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> crawling<br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">switch</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> state </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
stopped</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-prettify">do</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> something<br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">case</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> paused</span><span style=3D"color: #66=
0;" 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">do</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> something<br> &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">break</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> run=
ning</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">do</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> something<br> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">break</span><span style=3D"colo=
r: #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">case</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> walking</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">do</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> something<br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">break</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: #008;" class=3D"styled-by-prettify">c=
ase</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> crawli=
ng</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: #008;" class=3D"st=
yled-by-prettify">do</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> something<br> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">}</span></div></code></div><div><br></div><div>&nbs=
p;</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7159_28015337.1388655628820--
.
Author: Evgeny Panasyuk <evgeny.panasyuk@gmail.com>
Date: Thu, 2 Jan 2014 02:00:26 -0800 (PST)
Raw View
------=_Part_7449_8274447.1388656826756
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
19 nov 2013 =C7., 4:01:40 UTC+4 Billy O'Neal:
>
> My point in that answer is that
> 1. I see lots of people claim this jump table thing on switches.
> 2. I have never seen an actual program have a performance advantage by=20
> using a switch over an if/elseif ladder.
> 3. I have never seen an actual compiler generate the supposed "jump table=
"=20
> (though admittedly I don't make a habit of examining lots of assembly cod=
e).
>
> If someone would show data describing an actual program compiled with=20
> a modern compiler where the choice of switch vs. if made a measurable=20
> performance difference, then I could be convinced otherwise.
>
I have made such test several years ago:=20
http://img856.imageshack.us/img856/6497/resultx64multipleseries.png
switch, as well as virtual call, shows O(1) behavior, while binary search=
=20
with nested if ("if-else_O(log(N))" on figure) shows O(log(N)) behavior.
--=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_7449_8274447.1388656826756
Content-Type: text/html; charset=KOI8-R
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">19 nov 2013 =C7., 4:01:40 UTC+4 Billy O'Neal:<blockqu=
ote 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>My point in that=
answer is that</div><div>1. I see lots of people claim this jump table thi=
ng on switches.</div><div>2. I have never seen an actual program have a per=
formance advantage by using a switch over an if/elseif ladder.</div>
<div>3. I have never seen an actual compiler generate the supposed "jump ta=
ble" (though admittedly I don't make a habit of examining lots of assembly =
code).</div><div><br></div><div>If someone would show data describing an ac=
tual program compiled with a modern compiler where the choice of switc=
h vs. if made a measurable performance difference, then I could be convince=
d otherwise.</div></div></blockquote><div><br>I have made such test several=
years ago: http://img856.imageshack.us/img856/6497/resultx64multipleseries=
..png<br>switch, as well as virtual call, shows O(1) behavior, while binary =
search with nested if ("if-else_O(log(N))" on figure) shows O(log(N)) behav=
ior.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7449_8274447.1388656826756--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 02 Jan 2014 11:45:19 -0200
Raw View
On quinta-feira, 2 de janeiro de 2014 17:48:29, Troy Heron wrote:
> This also produces a jump table with clang:
>
> extern void a(), b(), c(), d(), e(), f(), g(), h();
>
> void jump(int i) {
> switch (i) {
> //case 0: return a();
> case 1: return b();
> case 2: return c();
> //case 3: return d();
> //case 4: return e();
> case 5: return f();
> // case 6: return g();
> case 7: return h();
> }
> }
>
> Notice the lack of starting at 0 or contiguousness of the case values?
Now try values that are powers of two (1, 2, 4, 8, 16, ...), with holes, and
compile in position-independent code.
--
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: "Billy O'Neal" <billy.oneal@gmail.com>
Date: Thu, 2 Jan 2014 11:08:44 -0800
Raw View
--089e013a1822210bde04ef0188e8
Content-Type: text/plain; charset=ISO-8859-1
> I wouldn't think that switching on an enum is an edge case:
I actually don't see that too often. Most often there will be a switch with
something like WM_ message codes or NTSTATUS codes -- which are large
numbers spaced far apart.
Billy O'Neal
https://github.com/BillyONeal/ <https://bitbucket.org/BillyONeal/>
http://stackoverflow.com/users/82320/billy-oneal
On Thu, Jan 2, 2014 at 1:40 AM, <dsanchez@cires21.com> wrote:
>
> Note that your example has a whole bunch of edge cases that make it
>> attractive to turn into a jump table:
>> 1. There are a large number of branches in the switch
>> 2. The branches form a contiguous run of consecutive numbers
>> 3. The consecutive run of numbers includes 0
>>
>> The argument I made here and in the StackOverflow answer is that I've
>> seen very few programs which meet this kind of criteria -- and that doing
>> simple binary search on the switch targets runs into no such generality
>> problems.
>>
>
> I wouldn't think that switching on an enum is an edge case:
>
> enum State
> {
> stopped,
> paused,
> running,
> walking,
> crawling
> };
>
>
> switch( state )
> {
> case stopped:
> do something
> break;
> case paused:
> do something
> break;
> case running:
> do something
> break;
> case walking:
> do something
> break;
> case crawling:
> do something
> break;
> }
>
>
>
> --
>
> ---
> 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/.
--089e013a1822210bde04ef0188e8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=A0<span style=3D"font-family:arial,sans-serif;font-si=
ze:13px">I wouldn't think that switching on an enum is an edge case:</s=
pan><div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></=
span></div>
<div><font face=3D"arial, sans-serif">I actually don't see that too oft=
en. Most often there will be a switch with something like WM_ message codes=
or NTSTATUS codes -- which are large numbers spaced far apart.</font></div=
>
</div><div class=3D"gmail_extra"><br clear=3D"all"><div><div dir=3D"ltr"><d=
iv>Billy O'Neal</div><div><a href=3D"https://bitbucket.org/BillyONeal/"=
target=3D"_blank">https://github.com/BillyONeal/</a></div><div><a href=3D"=
http://stackoverflow.com/users/82320/billy-oneal" target=3D"_blank">http://=
stackoverflow.com/users/82320/billy-oneal</a></div>
</div></div>
<br><br><div class=3D"gmail_quote">On Thu, Jan 2, 2014 at 1:40 AM, <span d=
ir=3D"ltr"><<a href=3D"mailto:dsanchez@cires21.com" target=3D"_blank">ds=
anchez@cires21.com</a>></span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><div><span style=3D"font-family:arial,sans-serif;font-=
size:13px">Note that your example has a whole bunch of edge cases that make=
it attractive to turn into a jump table:</span></div>
<div><font face=3D"arial, sans-serif">1. There are a large number of branch=
es in the switch</font></div><div><font face=3D"arial, sans-serif">2. The b=
ranches form a contiguous run of consecutive numbers</font></div><div><font=
face=3D"arial, sans-serif">3. The consecutive run of numbers includes 0</f=
ont></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">The argument I made here and in the StackOverflow answer =
is that I've seen very few programs which meet this kind of criteria --=
and that doing simple binary search on the switch targets runs into no=A0s=
uch generality problems.</font></div>
</div></blockquote><div><br></div></div><div>I wouldn't think that swit=
ching on an enum is an edge case:</div><div><br></div><div style=3D"backgro=
und-color:rgb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:brea=
k-word">
<code><div><span style=3D"color:#008">enum</span><span style> </span><span =
style=3D"color:#606">State</span><span style><br></span><span style=3D"colo=
r:#660">{</span><span style><br>=A0 =A0 stopped</span><span style=3D"color:=
#660">,</span><span style><br>
=A0 =A0 paused</span><span style=3D"color:#660">,</span><span style><br>=A0=
=A0 running</span><span style=3D"color:#660">,</span><span style><br>=A0 =
=A0 walking</span><span style=3D"color:#660">,</span><span style><br>=A0 =
=A0 crawling<br></span><span style=3D"color:#660">};</span><span style><br>
<br><br></span><span style=3D"color:#008">switch</span><span style=3D"color=
:#660">(</span><span style> state </span><span style=3D"color:#660">)</span=
><span style><br></span><span style=3D"color:#660">{</span><span style><br>=
=A0 =A0 </span><span style=3D"color:#008">case</span><span style> stopped</=
span><span style=3D"color:#660">:</span><span style><br>
=A0 =A0 =A0 =A0 =A0 =A0</span><span style=3D"color:#008">do</span><span sty=
le> something<br>=A0 =A0 =A0 =A0 </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style><br>=A0 =A0 </span><span=
style=3D"color:#008">case</span><span style> paused</span><span style=3D"c=
olor:#660">:</span><span style><br>
=A0 =A0 =A0 =A0 =A0 =A0</span><span style=3D"color:#008">do</span><span sty=
le> something<br>=A0 =A0 =A0 =A0 </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style><br>=A0 =A0 </span><span=
style=3D"color:#008">case</span><span style> running</span><span style=3D"=
color:#660">:</span><span style><br>
=A0 =A0 =A0 =A0 =A0 =A0</span><span style=3D"color:#008">do</span><span sty=
le> something<br>=A0 =A0 =A0 =A0 </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style><br>=A0 =A0 </span><span=
style=3D"color:#008">case</span><span style> walking</span><span style=3D"=
color:#660">:</span><span style><br>
=A0 =A0 =A0 =A0 =A0 =A0</span><span style=3D"color:#008">do</span><span sty=
le> something<br>=A0 =A0 =A0 =A0 </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style><br>=A0 =A0 </span><span=
style=3D"color:#008">case</span><span style> crawling</span><span style=3D=
"color:#660">:</span><span style><br>
=A0 =A0 =A0 =A0 =A0 =A0</span><span style=3D"color:#008">do</span><span sty=
le> something<br>=A0 =A0 =A0 =A0 </span><span style=3D"color:#008">break</s=
pan><span style=3D"color:#660">;</span><span style><br></span><span style=
=3D"color:#660">}</span></div>
</code></div><div><br></div><div>=A0</div></div><div class=3D"HOEnZb"><div =
class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013a1822210bde04ef0188e8--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 02 Jan 2014 15:01:32 -0500
Raw View
On 2014-01-02 14:08, Billy O'Neal wrote:
>> I wouldn't think that switching on an enum is an edge case:
>
> I actually don't see that too often. Most often there will be a switch with
> something like WM_ message codes or NTSTATUS codes -- which are large
> numbers spaced far apart.
It must depend on what code you work on. I'm sure I can find probably a
half dozen or more cases of switching on an enum in the project I'm
currently working on, and would expect to increase that by 3x or so if I
extend the search to projects I'm currently using (but not actively
hacking on).
At the very least, I know we have things like:
enum Columns // mnemonic of column in multi-column tree view
{
...
}
....
switch (column)
{
...
}
....and there are similar constructs with Qt data roles that tend to be
tightly-packed, mostly contiguous values covering maybe a dozen or so
'case's. So they definitely *do* show up in real code.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 10 Jan 2014 16:57:48 -0500
Raw View
On 2013-12-31 05:05, Andrew Tomazos wrote:
> Thanks for your feedback guys.
>
> My current design has "explicit switch" substituted for "safe_switch"
I keep thinking about this, and really, if it were me I would *much*
rather have the ability to make all switches safe by default than be
required to learn something new (and worse, to modify all of my existing
code) to get safety.
If we just standardized '[[fallthrough]]' instead, compilers don't
*technically* need to change at all, plus we already have at least one
reference implementation (clang) for how it's meant to be handled.
Or we could go one further and just make implicit fallthrough
ill-formed, period. (And expect/encourage compilers to provide a flag to
permit it in order to compile old, non-conforming code.)
Also, using [[fallthrough]] is much more conducive to macro-wrapping so
that code can still be build also on older compilers (and even that
isn't required if all target compilers support generic attributes).
> and the new jump statements:
>
> goto case <expr>
> goto switch
>
> Note that <expr> is not required to be a constant expression, but if it is
> constant than there is required to be a case with that value. The
> non-constant version could be caught by default or fall off the end if
> there is no default.
Um... I guess I hadn't read closely enough before. So what you are
saying here is that 'goto case <expr>' is really 'go back to the code
that evaluated the original 'switch' and reevaluate with '<expr>'?
I can imagine that might, in at least some cases, make work rather
harder for the compiler.
(I'm going to guess there should also be a 'goto default' there, as
'goto case default' sounds a little odd and isn't consistent with how
cases are declared.)
I'm not fundamentally opposed to a 'goto case', but I have some
inclination to want it as a separate proposal, as I can readily see it
being much more controversial, and I'd hate to see explicit fallthrough
miss the boat as a result.
In fact I feel like there are (or should be) three separate proposals here:
1. Deprecate implicit fallthrough (and add mechanism to make it explicit).
2. Make it more convenient to jump to a different switch case that is
other than simple fallthrough (e.g. to fallthrough without completing
the current case, or jump to an entirely other case).
3. Add a new kind of 'switch' that is implicitly scoped and has strict
fallthrough rules (i.e. only fallthrough if the case block is empty) to
allow 'break' to be elided.
One other reason I'd strongly prefer to see (1) decoupled from (3) is
that (3), like e.g. lambdas, simply cannot be used in code that needs to
compile on older compilers, whereas (1) can trivially be leveraged to
use new compilers to validate correctness while still compiling on old
compilers. (You *might* be able to emulate (3) with a lot of ugly
preprocessor 'sugar' if you really had to. Although that sugar would
likely be uglier than just using braces around all of your case's.)
> goto switch jumps to the smallest enclosing switch statement. It is just
> like goto label for some invented label that is just before the switch
> statement.
I can't think that I've ever needed this (and if so, it is easy enough
to synthesize by adding an enclosing loop). What is your use case for this?
> I've also got a design for a spec that has implicit fallthrough ill-formed
> (really ill-formed) in an explicit switch. I was going to chat to the
> undefined behaviour group about it to see if we also want to use in falling
> off the end of a value-returning function.
Heh. If you're talking about -Wreturn-type, that really ought to be an
error, with some mechanism to suppress it in the rare situations where
it is actually desired :-).
Again, I would strongly prefer that to become the *normal* behavior,
without syntax changes, such that the benefit is realized for all
existing code. (For all of my code, that is already the case, as I
routinely build with -Werror=return-type.)
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 11 Jan 2014 00:25:42 +0200
Raw View
On 10 January 2014 23:57, Matthew Woehlke
<mw_triad@users.sourceforge.net> wrote:
> I keep thinking about this, and really, if it were me I would *much* rather
> have the ability to make all switches safe by default than be required to
> learn something new (and worse, to modify all of my existing code) to get
> safety.
Many of us would much rather do that, in a perfect world equipped with
time machines. :)
> If we just standardized '[[fallthrough]]' instead, compilers don't
> *technically* need to change at all, plus we already have at least one
> reference implementation (clang) for how it's meant to be handled.
This sounds palatable to me.
> Or we could go one further and just make implicit fallthrough ill-formed,
> period. (And expect/encourage compilers to provide a flag to permit it in
> order to compile old, non-conforming code.)
We could try. Whatever my personal opinions on it (which are against it), I
would have no choice but to vote against such a proposal, and vote against
any standard that would include such a proposal. It breaks so much existing
code that it's an absolute no-go. You said you don't want to modify all
your existing code to get safety. I don't want to modify a massive amount
of existing code just because someone thought correct code is unsafe
and must be broken to gain safety for new code.
> 1. Deprecate implicit fallthrough (and add mechanism to make it explicit).
I don't think we serve anyone by deprecating with no intention to ever
remove. That has happened before, and it was mostly just a source
of confusion.
> 2. Make it more convenient to jump to a different switch case that is other
> than simple fallthrough (e.g. to fallthrough without completing the current
> case, or jump to an entirely other case).
I don't know why goto is so inconvenient for people. It has correct and
valid uses, even in Dijkstra's writings.
> 3. Add a new kind of 'switch' that is implicitly scoped and has strict
> fallthrough rules (i.e. only fallthrough if the case block is empty) to
> allow 'break' to be elided.
This would be the correct approach imho, instead of mucking with the
semantics of the existing switch.
--
---
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: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 10 Jan 2014 17:33:37 -0500
Raw View
On 2014-01-10 17:25, Ville Voutilainen wrote:
> On 10 January 2014 23:57, Matthew Woehlke wrote:
>> Or we could go one further and just make implicit fallthrough ill-formed,
>> period. (And expect/encourage compilers to provide a flag to permit it in
>> order to compile old, non-conforming code.)
>
> We could try. Whatever my personal opinions on it (which are against it), I
> would have no choice but to vote against such a proposal, and vote against
> any standard that would include such a proposal. It breaks so much existing
> code that it's an absolute no-go. You said you don't want to modify all
> your existing code to get safety. I don't want to modify a massive amount
> of existing code just because someone thought correct code is unsafe
> and must be broken to gain safety for new code.
The objective here would be for gradual deprecation, i.e. so that at
some future point we would be able to 'pull the plug' entirely on such
old code (and/or require that to build it you must request and old
standard version). I too would only be okay with this if compilers
allowed the code to build anyway even though the standard would say it
is ill-formed.
I feel that there could be benefit to doing so, but don't feel strongly
that we need to :-). So, just a suggestion...
>> 2. Make it more convenient to jump to a different switch case that is other
>> than simple fallthrough (e.g. to fallthrough without completing the current
>> case, or jump to an entirely other case).
>
> I don't know why goto is so inconvenient for people. It has correct and
> valid uses, even in Dijkstra's writings.
Well, Andrew's proposal *does* use 'goto'. Really, it's just about
having 'case <...>' be an implicit label for 'goto'. (If you exclude the
non-const version, anyway. I'll admit, the non-const makes me nervous...)
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 10 Jan 2014 17:39:49 -0600
Raw View
--047d7bb04c444d2a9d04efa64062
Content-Type: text/plain; charset=ISO-8859-1
On 10 January 2014 16:33, Matthew Woehlke <mw_triad@users.sourceforge.net>wrote:
> On 2014-01-10 17:25, Ville Voutilainen wrote:
>
> On 10 January 2014 23:57, Matthew Woehlke wrote:
>>
>>> Or we could go one further and just make implicit fallthrough ill-formed,
>>> period. (And expect/encourage compilers to provide a flag to permit it in
>>> order to compile old, non-conforming code.)
>>>
>>
>> We could try. Whatever my personal opinions on it (which are against it),
>> I
>> would have no choice but to vote against such a proposal, and vote against
>> any standard that would include such a proposal. It breaks so much
>> existing
>> code that it's an absolute no-go. You said you don't want to modify all
>> your existing code to get safety. I don't want to modify a massive amount
>> of existing code just because someone thought correct code is unsafe
>> and must be broken to gain safety for new code.
>>
>
> The objective here would be for gradual deprecation,
Which would be a gratuitous incompatibility with C, giving the committee an
additional reason to reject it.
As there is only a little to be gained by addressing this, I would be
weakly for an attribute and against all the other solutions discussed (lots
of effort, new error proneness, etc.), were someone to propose it.
Alternatively, you could try and get the C committee to address this first,
although I suspect Ville's point about breaking existing code (which I
wholeheartedly agree with) would make it a non-starter there too.
--
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/.
--047d7bb04c444d2a9d04efa64062
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 10 January 2014 16:33, Matthew Woehlke <span dir=3D"ltr=
"><<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_blank">m=
w_triad@users.sourceforge.net</a>></span> wrote:<br><div class=3D"gmail_=
extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-01-10 17:=
25, Ville Voutilainen wrote:<div class=3D"im"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 10 January 2014 23:57, Matthew Woehlke wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Or we could go one further and just make implicit fallthrough ill-formed,<b=
r>
period. (And expect/encourage compilers to provide a flag to permit it in<b=
r>
order to compile old, non-conforming code.)<br>
</blockquote>
<br>
We could try. Whatever my personal opinions on it (which are against it), I=
<br>
would have no choice but to vote against such a proposal, and vote against<=
br>
any standard that would include such a proposal. It breaks so much existing=
<br>
code that it's an absolute no-go. You said you don't want to modify=
all<br>
your existing code to get safety. I don't want to modify a massive amou=
nt<br>
of existing code just because someone thought correct code is unsafe<br>
and must be broken to gain safety for new code.<br>
</blockquote>
<br></div>
The objective here would be for gradual deprecation,</blockquote><div><br><=
/div><div>Which would be a gratuitous incompatibility with C, giving the co=
mmittee an additional reason to reject it.<br><br></div><div>As there is on=
ly a little to be gained by addressing this, I would be weakly for an attri=
bute and against all the other solutions discussed (lots of effort, new err=
or proneness, etc.), were someone to propose it.<br>
<br></div><div>Alternatively, you could try and get the C committee to addr=
ess this first, although I suspect Ville's point about breaking existin=
g code (which I wholeheartedly agree with) would make it a non-starter ther=
e too.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7bb04c444d2a9d04efa64062--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 11 Jan 2014 01:49:39 +0200
Raw View
On 11 January 2014 01:39, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 10 January 2014 16:33, Matthew Woehlke <mw_triad@users.sourceforge.net>
> wrote:
>> The objective here would be for gradual deprecation,
> Which would be a gratuitous incompatibility with C, giving the committee an
> additional reason to reject it.
Thanks, Nevin, that's an excellent additional point which I failed to mention.
Further 0.02: yes, we do try and make C++ easier for non-experts, with varying
degrees of success, but we don't do it at any cost. The cost of changing the
semantics of switch-case is MUCH too high. The legacy codebases I can see and
know of are full of implicit fall-through (and some contain Duff's devices
and its ilk), like it or not, and as hard as it may be to guesstimate, I have
a vague assumption that that is just the minuscule tip of the iceberg.
Breaking all that code will merely result in a massive backlash amongst
the owners/maintainers of such legacy codebases, and they _will_ contact
National Bodies and raise hell about it. And no, they are not so legacy that
they will not consider upgrading to a newer C++ standard. The legacy doesn't
remain dormant, nor does it die - it keeps haunting us. ;)
This is why I've recommended people to rename their "safe switch". Find whatever
alternative name or a completely different solution, but don't muck with the
existing switch. Or if you HAVE to muck with it, do so in a legacy-compatible
manner. Otherwise it'll be nuked from the orbit before you'll get to
round 2 with
your proposal.
--
---
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: Tony V E <tvaneerd@gmail.com>
Date: Sat, 11 Jan 2014 07:07:44 -0000
Raw View
--001a11c2432ae1343104efac7f75
Content-Type: text/plain; charset=ISO-8859-1
Just a thought:
"fallthrough" could be spelled "case++". Obviously meaning "go to the next
case".
:-)
Sent from my portable Analytical Engine
------------------------------
--
---
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/.
--001a11c2432ae1343104efac7f75
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html><head></head><body>Just a thought:<div><br></div><div>"fallthrou=
gh" could be spelled "case++". =A0Obviously meaning "go=
to the next case".</div><div><br></div><div>:-)<br><br><div id=3D"133=
0154144936-sig-id">
Sent from my portable Analytical Engine </div><br><hr><div><br></div></div>=
</body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a11c2432ae1343104efac7f75--
.
Author: inkwizytoryankes@gmail.com
Date: Sat, 11 Jan 2014 06:24:11 -0800 (PST)
Raw View
------=_Part_253_15741849.1389450251455
Content-Type: text/plain; charset=ISO-8859-1
Some kind of [[safe]] switch that only reject code without changing switch
behavior is probably best solution. All old code will work with new
compilers without change, all new code will work in old compiler without
change.
Additional thing is if you dont want add it everywhere, compile could add
flag that add safe attribute to all switch in code (maybe except switch
with [[nosafe]] to prevent rewriting old code).
On Saturday, January 11, 2014 12:49:39 AM UTC+1, Ville Voutilainen wrote:
>
> On 11 January 2014 01:39, Nevin Liber <ne...@eviloverlord.com<javascript:>>
> wrote:
> > On 10 January 2014 16:33, Matthew Woehlke <mw_t...@users.sourceforge.net<javascript:>>
>
> > wrote:
> >> The objective here would be for gradual deprecation,
> > Which would be a gratuitous incompatibility with C, giving the committee
> an
> > additional reason to reject it.
>
> Thanks, Nevin, that's an excellent additional point which I failed to
> mention.
>
> Further 0.02: yes, we do try and make C++ easier for non-experts, with
> varying
> degrees of success, but we don't do it at any cost. The cost of changing
> the
> semantics of switch-case is MUCH too high. The legacy codebases I can see
> and
> know of are full of implicit fall-through (and some contain Duff's devices
> and its ilk), like it or not, and as hard as it may be to guesstimate, I
> have
> a vague assumption that that is just the minuscule tip of the iceberg.
> Breaking all that code will merely result in a massive backlash amongst
> the owners/maintainers of such legacy codebases, and they _will_ contact
> National Bodies and raise hell about it. And no, they are not so legacy
> that
> they will not consider upgrading to a newer C++ standard. The legacy
> doesn't
> remain dormant, nor does it die - it keeps haunting us. ;)
>
> This is why I've recommended people to rename their "safe switch". Find
> whatever
> alternative name or a completely different solution, but don't muck with
> the
> existing switch. Or if you HAVE to muck with it, do so in a
> legacy-compatible
> manner. Otherwise it'll be nuked from the orbit before you'll get to
> round 2 with
> your proposal.
>
--
---
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_253_15741849.1389450251455
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some kind of [[safe]] switch that only reject code without=
changing switch behavior is probably best solution. All old code will work=
with new compilers without change, all new code will work in old compiler =
without change.<br>Additional thing is if you dont want add it everywhere, =
compile could add flag that add safe attribute to all switch in code (maybe=
except switch with [[nosafe]] to prevent rewriting old code).<br><br>On Sa=
turday, January 11, 2014 12:49:39 AM UTC+1, Ville Voutilainen wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On 11 January 2014 01:39, Nevin Liber=
<<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ksV=
TYtSgi10J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a>> =
wrote:
<br>> On 10 January 2014 16:33, Matthew Woehlke <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"ksVTYtSgi10J" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">mw_t...@users.sourceforge.<wbr>net</a>>
<br>> wrote:
<br>>> The objective here would be for gradual deprecation,
<br>> Which would be a gratuitous incompatibility with C, giving the com=
mittee an
<br>> additional reason to reject it.
<br>
<br>Thanks, Nevin, that's an excellent additional point which I failed to m=
ention.
<br>
<br>Further 0.02: yes, we do try and make C++ easier for non-experts, with =
varying
<br>degrees of success, but we don't do it at any cost. The cost of changin=
g the
<br>semantics of switch-case is MUCH too high. The legacy codebases I can s=
ee and
<br>know of are full of implicit fall-through (and some contain Duff's devi=
ces
<br>and its ilk), like it or not, and as hard as it may be to guesstimate, =
I have
<br>a vague assumption that that is just the minuscule tip of the iceberg.
<br>Breaking all that code will merely result in a massive backlash amongst
<br>the owners/maintainers of such legacy codebases, and they _will_ contac=
t
<br>National Bodies and raise hell about it. And no, they are not so legacy=
that
<br>they will not consider upgrading to a newer C++ standard. The legacy do=
esn't
<br>remain dormant, nor does it die - it keeps haunting us. ;)
<br>
<br>This is why I've recommended people to rename their "safe switch". Find=
whatever
<br>alternative name or a completely different solution, but don't muck wit=
h the
<br>existing switch. Or if you HAVE to muck with it, do so in a legacy-comp=
atible
<br>manner. Otherwise it'll be nuked from the orbit before you'll get to
<br>round 2 with
<br>your proposal.
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_253_15741849.1389450251455--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 12 Jan 2014 22:32:24 -0800 (PST)
Raw View
------=_Part_3078_28678479.1389594744806
Content-Type: text/plain; charset=ISO-8859-1
Thanks to everyone for their further feedback and ideas on my draft safe
switch proposal.
I just want to clarify and reiterate a couple of points:
- In no version of the proposal are the semantics (or even the
diagnostic-generation) of existing code changed. It simply isn't possible.
The committee will simply be ignored if they try to, and people will
simply not upgrade their compilers if they "stop working" on their existing
code (see Python 2.7 vs 3.0 or Perl 5 vs 6 for case studies). Language
designers misinterpret the loyalty of the programmers to their own code for
loyalty to the language the code is written in. (Put another way: If it
were possible to write language-agnostic code somehow, programmers would do
so without a second though). Even a global compiler option that changes
the diagnostic-generation of existing code (such as
-Wno-implicit-fallthrough), if provided by an implementation, will simply
not be used and ignored. If a feature of the language is poorly designed
and people use it, all we can do is either (a) live with it, or (b) if it
is really bad (like implicit fallthrough) add a new feature that offers a
better alternative.
- The proposal involves allowing the programmer, if they want, to add an
*optional* explicit-specifier to their switch statements. The main effect
is that implicit fallthrough will be ill-formed in these explicit switch
statements. Existing non-explicit switch statements remain with implicit
fallthrough well-formed. As a general replacement for the now ill-formed
fallthrough semantic in explicit switches, we propose
sideporting/reintroducing the goto case statement (from BCPL and C#). Even
if you ignore BCPL as a predecessor to B and C from the 1960s - C# provides
an enormous modern existing practice for the goto case statement.
- The question has been raised about the goto case statement requiring
repetition of the label. ie Instead of this use of implicit fallthrough
from foo to bar:
switch (conditon)
{
case foo:
...
case bar:
...
};
Under the proposal you can *optionally* write it this way instead:
explicit switch (conditon)
{
case foo:
...
goto case bar;
case bar:
...
};
This requires repeating bar to bind the flow from foo to bar. This
explicit binding is actually a good thing and a feature. A frequent source
of bugs is when a second programmer inserts a new case into the switch and
doesn't notice that the case immediately above is using fallthrough:
switch (conditon)
{
case foo:
...
// new feature added
case baz:
...
break;
case bar:
...
};
Oops, condition foo now does foo-baz and not foo-bar. Expensive run-time
logic bug ensues.
explicit switch (conditon)
{
case foo:
...
goto case bar;
// new feature added
case baz:
...
break;
case bar:
...
};
Everything still works in this explicit version, with the second programmer
blissfully unaware. The bug would still be present with a fallthrough
statement or [[fallthrough]] attribute statement.
- I accidentally omitted mentioning goto default which is a type of goto
case statement in my updates in this thread. goto default hasn't been
dropped from the proposal.
- The additional goto switch and goto case <non-constant-expression>
version would allow for some looping constructs that currently require
introducing labels. For example the following frequently-used pattern:
bool keep_going = true;
while (keep_going) switch (condition)
{
case foo:
...
keep_going = false;
break;
case bar:
...
continue;
case baz:
...
condition = f();
break;
case qux:
...
keep_going = false;
break;
};
Could optionally be replaced by the much clearer:
switch (condition)
{
case foo:
...
break;
case bar:
...
goto switch;
case baz:
...
goto case f();
case qux:
...
};
- Everything mentioned so far in this thread and the proposal has extremely
low implementation-difficulty.
- Finally, I would like to comment that this is something for C++17 - so we
have a long time to think about it, so although all feedback is always
welcome - brainstorming, ideas and constructive feedback would be
appreciated more than the other kinds.
Thanks again,
Andrew.
On Saturday, January 11, 2014 12:49:39 AM UTC+1, Ville Voutilainen wrote:
>
> On 11 January 2014 01:39, Nevin Liber <ne...@eviloverlord.com<javascript:>>
> wrote:
> > On 10 January 2014 16:33, Matthew Woehlke <mw_t...@users.sourceforge.net<javascript:>>
>
> > wrote:
> >> The objective here would be for gradual deprecation,
> > Which would be a gratuitous incompatibility with C, giving the committee
> an
> > additional reason to reject it.
>
> Thanks, Nevin, that's an excellent additional point which I failed to
> mention.
>
> Further 0.02: yes, we do try and make C++ easier for non-experts, with
> varying
> degrees of success, but we don't do it at any cost. The cost of changing
> the
> semantics of switch-case is MUCH too high. The legacy codebases I can see
> and
> know of are full of implicit fall-through (and some contain Duff's devices
> and its ilk), like it or not, and as hard as it may be to guesstimate, I
> have
> a vague assumption that that is just the minuscule tip of the iceberg.
> Breaking all that code will merely result in a massive backlash amongst
> the owners/maintainers of such legacy codebases, and they _will_ contact
> National Bodies and raise hell about it. And no, they are not so legacy
> that
> they will not consider upgrading to a newer C++ standard. The legacy
> doesn't
> remain dormant, nor does it die - it keeps haunting us. ;)
>
> This is why I've recommended people to rename their "safe switch". Find
> whatever
> alternative name or a completely different solution, but don't muck with
> the
> existing switch. Or if you HAVE to muck with it, do so in a
> legacy-compatible
> manner. Otherwise it'll be nuked from the orbit before you'll get to
> round 2 with
> your proposal.
>
--
---
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_3078_28678479.1389594744806
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks to everyone for their further feedback and ideas on=
my draft safe switch proposal.<br><br>I just want to clarify and reiterate=
a couple of points:<div><br></div><div>- In no version of the proposal are=
the semantics (or even the diagnostic-generation) of existing code changed=
.. It simply isn't possible. The committee will simply be ignore=
d if they try to, and people will simply not upgrade their compilers if the=
y "stop working" on their existing code (see Python 2.7 vs 3.0 or Perl 5 vs=
6 for case studies). Language designers misinterpret the loyalty of =
the programmers to their own code for loyalty to the language the code is w=
ritten in. (Put another way: If it were possible to write language-ag=
nostic code somehow, programmers would do so without a second though). &nbs=
p;Even a global compiler option that changes the diagnostic-generation of e=
xisting code (such as -Wno-implicit-fallthrough), if provided by an impleme=
ntation, will simply not be used and ignored. If a feature of the lan=
guage is poorly designed and people use it, all we can do is either (a) liv=
e with it, or (b) if it is really bad (like implicit fallthrough) add a new=
feature that offers a better alternative.</div><div><br></div><div>- The p=
roposal involves allowing the programmer, if they want, to add an *optional=
* explicit-specifier to their switch statements. The main effect is t=
hat implicit fallthrough will be ill-formed in these explicit switch statem=
ents. Existing non-explicit switch statements remain with implicit fa=
llthrough well-formed. As a general replacement for the now ill-forme=
d fallthrough semantic in explicit switches, we propose sideporting/reintro=
ducing the goto case statement (from BCPL and C#). Even if you ignore=
BCPL as a predecessor to B and C from the 1960s - C# provides an enormous =
modern existing practice for the goto case statement.</div><div><br></div><=
div>- The question has been raised about the goto case statement requiring =
repetition of the label. ie Instead of this use of implicit fallthrou=
gh from foo to bar:</div><div><br></div><div><font face=3D"courier new, mon=
ospace"> switch (conditon)</font></div><div><font face=
=3D"courier new, monospace"> {</font></div><div><font fa=
ce=3D"courier new, monospace"> case foo:</font></div><di=
v><font face=3D"courier new, monospace"> .=
...</font></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><font face=3D"courier new, monospace"> case bar:</f=
ont></div><div><font face=3D"courier new, monospace"> &=
nbsp; ...</font></div><div><font face=3D"courier new, monospace">&nbs=
p; };</font></div><div><br></div><div>Under the proposal you c=
an *optionally* write it this way instead:</div><div><br></div><div><div><f=
ont face=3D"courier new, monospace"> explicit switch (co=
nditon)</font></div><div><font face=3D"courier new, monospace">  =
; {</font></div><div><font face=3D"courier new, monospace"> &nb=
sp; case foo:</font></div><div><font face=3D"courier new, monospace">=
...</font></div><div><font face=3D"courie=
r new, monospace"> goto case bar;</font></=
div><div><font face=3D"courier new, monospace"><br></font></div><div><font =
face=3D"courier new, monospace"> case bar:</font></div><=
div><font face=3D"courier new, monospace">  =
;...</font></div><div><font face=3D"courier new, monospace"> &=
nbsp;};</font></div></div><div><br></div><div>This requires repeating bar t=
o bind the flow from foo to bar. This explicit binding is actually a =
good thing and a feature. A frequent source of bugs is when a second =
programmer inserts a new case into the switch and doesn't notice that the c=
ase immediately above is using fallthrough:</div><div><br></div><div><div><=
font face=3D"courier new, monospace"> switch (conditon)<=
/font></div><div><font face=3D"courier new, monospace"> =
{</font></div><div><font face=3D"courier new, monospace"> &nbs=
p;case foo:</font></div><div><font face=3D"courier new, monospace"> &=
nbsp; ...</font></div><div><font face=3D"courier new, m=
onospace"><br></font></div><div><font face=3D"courier new, monospace"> =
; // new feature added</font></div><div><font face=3D"courier =
new, monospace"> case baz:</font></div><div><font face=
=3D"courier new, monospace"> ...</font></d=
iv><div><font face=3D"courier new, monospace"> &=
nbsp;break;</font></div><div><font face=3D"courier new, monospace"><br></fo=
nt></div><div><font face=3D"courier new, monospace"> cas=
e bar:</font></div><div><font face=3D"courier new, monospace"> =
...</font></div><div><font face=3D"courier new, monosp=
ace"> };</font></div></div><div><font face=3D"courier ne=
w, monospace"><br></font></div><div><font face=3D"arial, sans-serif">Oops, =
condition foo now does foo-baz and not foo-bar. Expensive run-time lo=
gic bug ensues.</font></div><div><br></div><div><div><div><font face=3D"cou=
rier new, monospace"> explicit switch (conditon)</font><=
/div><div><font face=3D"courier new, monospace"> {</font=
></div><div><font face=3D"courier new, monospace"> case =
foo:</font></div><div><font face=3D"courier new, monospace"> &=
nbsp; ...</font></div><div><font face=3D"courier new, monospac=
e"> goto case bar;</font></div><div><font =
face=3D"courier new, monospace"><br></font></div><div><div><font face=3D"co=
urier new, monospace"> // new feature added</font></div>=
<div><font face=3D"courier new, monospace"> case baz:</f=
ont></div><div><font face=3D"courier new, monospace"> &=
nbsp; ...</font></div><div><font face=3D"courier new, monospace">&nbs=
p; break;</font></div></div><div><br></div><div>=
<font face=3D"courier new, monospace"> case bar:</font><=
/div><div><font face=3D"courier new, monospace"> =
...</font></div><div><font face=3D"courier new, monospace"> &n=
bsp; };</font></div></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><font face=3D"arial, sans-serif">Everything still wor=
ks in this explicit version, with the second programmer blissfully unaware.=
The bug would still be present with a fallthrough statement or [[fal=
lthrough]] attribute statement.</font></div><div><br></div><div>- I acciden=
tally omitted mentioning goto default which is a type of goto case statemen=
t in my updates in this thread. goto default hasn't been dropped from=
the proposal.</div><div><br></div><div>- The additional goto switch and go=
to case <non-constant-expression> version would allow for some loopin=
g constructs that currently require introducing labels. For example t=
he following frequently-used pattern:</div><div><br></div><div><span style=
=3D"font-family: 'courier new', monospace;"> bool keep_going =
=3D true;</span><br></div><div><font face=3D"courier new, monospace"> =
while (keep_going) switch (condition)</font></div><div><font face=
=3D"courier new, monospace"> {</font></div><div><font face=3D"=
courier new, monospace"> case foo:</font></div><div><font face=
=3D"courier new, monospace"> ...</font></div><di=
v><font face=3D"courier new, monospace"> keep_go=
ing =3D false;</font></div><div><font face=3D"courier new, monospace"> =
; break;</font></div><div><font face=3D"courier new, m=
onospace"><br></font></div><div><font face=3D"courier new, monospace"> =
; case bar:</font></div><div><font face=3D"courier new, monospace">&=
nbsp; ...</font></div><div><font face=3D"courier new, =
monospace"> continue;</font></div><div><font fac=
e=3D"courier new, monospace"><br></font></div><div><font face=3D"courier ne=
w, monospace"> case baz:</font></div><div><font face=3D"courie=
r new, monospace"> ...</font></div><div><font fa=
ce=3D"courier new, monospace"> condition =3D f()=
;</font></div><div><font face=3D"courier new, monospace"> &nbs=
p; break;</font></div><div><font face=3D"courier new, monospace"><br=
></font></div><div><font face=3D"courier new, monospace"> case=
qux:</font></div><div><font face=3D"courier new, monospace"> =
...</font></div><div><font face=3D"courier new, monospace">&n=
bsp; keep_going =3D false;</font></div><div><font face=
=3D"courier new, monospace"> break;</font></div>=
<div><font face=3D"courier new, monospace"> };</font></div><di=
v><br></div><div>Could optionally be replaced by the much clearer:</div><di=
v><br></div><div><div><font face=3D"courier new, monospace"> &n=
bsp;</font><span style=3D"font-family: 'courier new', monospace;">switch (c=
ondition)</span></div><div><font face=3D"courier new, monospace"> &nb=
sp; {</font></div><div><font face=3D"courier new, monospace"> =
case foo:</font></div><div><font face=3D"courier new, monospace"> &nb=
sp; ...</font></div><div><span style=3D"font-family: 'courier=
new', monospace;"> break;</span><br></div><div>=
<font face=3D"courier new, monospace"><br></font></div><div><font face=3D"c=
ourier new, monospace"> case bar:</font></div><div><font face=
=3D"courier new, monospace"> ...</font></div><di=
v><font face=3D"courier new, monospace"> goto sw=
itch;</font></div><div><font face=3D"courier new, monospace"><br></font></d=
iv><div><font face=3D"courier new, monospace"> case baz:</font=
></div><div><font face=3D"courier new, monospace"> &nbs=
p; ...</font></div><div><font face=3D"courier new, monospace"> =
goto case f();</font></div><div><font face=3D"courier new, m=
onospace"><br></font></div><div><font face=3D"courier new, monospace"> =
; case qux:</font></div><div><font face=3D"courier new, monospace">&=
nbsp; ...</font></div><div><span style=3D"font-family:=
'courier new', monospace;"> };</span><br></div><div><font fac=
e=3D"courier new, monospace"><br></font></div><div><font face=3D"arial, san=
s-serif">- Everything mentioned so far in this thread and the proposal has =
extremely low implementation-difficulty.</font></div><font face=3D"courier =
new, monospace"><br></font></div><div>- Finally, I would like to comment th=
at this is something for C++17 - so we have a long time to think about it, =
so although all feedback is always welcome - brainstorming, ideas and const=
ructive feedback would be appreciated more than the other kinds.</div><div>=
<br></div><div>Thanks again,</div><div>Andrew.</div><div><br></div><br>On S=
aturday, January 11, 2014 12:49:39 AM UTC+1, Ville Voutilainen wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">On 11 January 2014 01:39, Nevin Libe=
r <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ks=
VTYtSgi10J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=
=3D"this.href=3D'javascript:';return true;">ne...@eviloverlord.com</a>> =
wrote:
<br>> On 10 January 2014 16:33, Matthew Woehlke <<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"ksVTYtSgi10J" onmousedown=3D=
"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript=
:';return true;">mw_t...@users.sourceforge.<wbr>net</a>>
<br>> wrote:
<br>>> The objective here would be for gradual deprecation,
<br>> Which would be a gratuitous incompatibility with C, giving the com=
mittee an
<br>> additional reason to reject it.
<br>
<br>Thanks, Nevin, that's an excellent additional point which I failed to m=
ention.
<br>
<br>Further 0.02: yes, we do try and make C++ easier for non-experts, with =
varying
<br>degrees of success, but we don't do it at any cost. The cost of changin=
g the
<br>semantics of switch-case is MUCH too high. The legacy codebases I can s=
ee and
<br>know of are full of implicit fall-through (and some contain Duff's devi=
ces
<br>and its ilk), like it or not, and as hard as it may be to guesstimate, =
I have
<br>a vague assumption that that is just the minuscule tip of the iceberg.
<br>Breaking all that code will merely result in a massive backlash amongst
<br>the owners/maintainers of such legacy codebases, and they _will_ contac=
t
<br>National Bodies and raise hell about it. And no, they are not so legacy=
that
<br>they will not consider upgrading to a newer C++ standard. The legacy do=
esn't
<br>remain dormant, nor does it die - it keeps haunting us. ;)
<br>
<br>This is why I've recommended people to rename their "safe switch". Find=
whatever
<br>alternative name or a completely different solution, but don't muck wit=
h the
<br>existing switch. Or if you HAVE to muck with it, do so in a legacy-comp=
atible
<br>manner. Otherwise it'll be nuked from the orbit before you'll get to
<br>round 2 with
<br>your proposal.
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3078_28678479.1389594744806--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Mon, 13 Jan 2014 11:38:51 -0500
Raw View
On 2014-01-11 09:24, inkwizytoryankes@gmail.com wrote:
> Some kind of [[safe]] switch that only reject code without changing switch
> behavior is probably best solution. All old code will work with new
> compilers without change, all new code will work in old compiler without
> change.
> Additional thing is if you dont want add it everywhere, compile could add
> flag that add safe attribute to all switch in code (maybe except switch
> with [[nosafe]] to prevent rewriting old code).
Yes, that is exactly my preference, and is already implemented by at
least clang with -W[error=]implicit-fallthrough and the
[[clang::fallthrough]] attribute, so there is existing precedent. It
would be nice to see the attributes standardized, however.
I don't have an objection to an attribute that effectively makes
implicit fallthrough an error for a particular switch (i.e. your
'[[safe]]' attribute, above). I have a preference for annotating the
actual occurrence of intended fallthrough versus disabling the
diagnostic entirely for a particular switch (either way you're changing
the code, but the explicit fallthrough is a better expression of
intent), but would be okay having both options available.
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Mon, 13 Jan 2014 15:10:13 -0800 (PST)
Raw View
------=_Part_774_29834125.1389654613183
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
@Andrew:
Just as you feel that the explicit goto case <next case>; to get a fall=20
through is "a good thing and a feature" even though it is more verbose I=20
think that having to write one of the loop statements (for, while,=20
do-while) to get a loop is "a good thing and a feature" for similar reasons=
=20
of "documentation of intention". This means that I don't like the goto=20
switch and goto case <expression> constucts as they may introduce a loop=20
without a loop statement. Otherwise I like your ideas including the new use=
=20
of the explicit keyword.
Noted, you can still implement a loop in a switch but goto has always been=
=20
able to make a loop in code. I would not oppose a suggestion to have the=20
compiler statically check explicit switch statements and disallow goto=20
loops, as they are more often than not bugs. Implementing a state machine=
=20
with a switch inside a loop is a very clean pattern to me, while looping=20
among switch cases without leaving the switch statement seems very ugly.
To remedy the little problem of getting out of the loop from inside the=20
switch I have previously suggested to allow multilevel break using the=20
syntax "break break;", which I feel would be quite intuitive. As nothing is=
=20
allowed after break today it can't really affect any current code. This can=
=20
be extended to "break continue;" and of course to break out of nested loops=
=20
as well.
Den m=E5ndagen den 13:e januari 2014 kl. 17:38:51 UTC+1 skrev Matthew Woehl=
ke:
>
> On 2014-01-11 09:24, inkwizyt...@gmail.com <javascript:> wrote:=20
> > Some kind of [[safe]] switch that only reject code without changing=20
> switch=20
> > behavior is probably best solution. All old code will work with new=20
> > compilers without change, all new code will work in old compiler withou=
t=20
> > change.=20
> > Additional thing is if you dont want add it everywhere, compile could=
=20
> add=20
> > flag that add safe attribute to all switch in code (maybe except switch=
=20
> > with [[nosafe]] to prevent rewriting old code).=20
>
> Yes, that is exactly my preference, and is already implemented by at=20
> least clang with -W[error=3D]implicit-fallthrough and the=20
> [[clang::fallthrough]] attribute, so there is existing precedent. It=20
> would be nice to see the attributes standardized, however.=20
>
> I don't have an objection to an attribute that effectively makes=20
> implicit fallthrough an error for a particular switch (i.e. your=20
> '[[safe]]' attribute, above). I have a preference for annotating the=20
> actual occurrence of intended fallthrough versus disabling the=20
> diagnostic entirely for a particular switch (either way you're changing=
=20
> the code, but the explicit fallthrough is a better expression of=20
> intent), but would be okay having both options available.=20
>
> --=20
> Matthew=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_774_29834125.1389654613183
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@Andrew:<div><br></div><div>Just as you feel that the expl=
icit goto case <next case>; to get a fall through is "a good thing an=
d a feature" even though it is more verbose I think that having to write on=
e of the loop statements (for, while, do-while) to get a loop is "a good th=
ing and a feature" for similar reasons of "documentation of intention". Thi=
s means that I don't like the goto switch and goto case <expression> =
constucts as they may introduce a loop without a loop statement. Otherwise =
I like your ideas including the new use of the explicit keyword.</div><div>=
<br></div><div>Noted, you can still implement a loop in a switch but goto h=
as always been able to make a loop in code. I would not oppose a suggestion=
to have the compiler statically check explicit switch statements and disal=
low goto loops, as they are more often than not bugs. Implementing a state =
machine with a switch inside a loop is a very clean pattern to me, while lo=
oping among switch cases without leaving the switch statement seems very ug=
ly.</div><div><br></div><div>To remedy the little problem of getting out of=
the loop from inside the switch I have previously suggested to allow multi=
level break using the syntax "break break;", which I feel would be quite in=
tuitive. As nothing is allowed after break today it can't really affect any=
current code. This can be extended to "break continue;" and of course to b=
reak out of nested loops as well.</div><div><br></div><div><br></div><div><=
br>Den m=E5ndagen den 13:e januari 2014 kl. 17:38:51 UTC+1 skrev Matthew Wo=
ehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-01-11 09:24, <a =
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"n24kaBcZlCY=
J" onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.h=
ref=3D'javascript:';return true;">inkwizyt...@gmail.com</a> wrote:
<br>> Some kind of [[safe]] switch that only reject code without changin=
g switch
<br>> behavior is probably best solution. All old code will work with ne=
w
<br>> compilers without change, all new code will work in old compiler w=
ithout
<br>> change.
<br>> Additional thing is if you dont want add it everywhere, compile co=
uld add
<br>> flag that add safe attribute to all switch in code (maybe except s=
witch
<br>> with [[nosafe]] to prevent rewriting old code).
<br>
<br>Yes, that is exactly my preference, and is already implemented by at=20
<br>least clang with -W[error=3D]implicit-fallthrough and the=20
<br>[[clang::fallthrough]] attribute, so there is existing precedent. It=20
<br>would be nice to see the attributes standardized, however.
<br>
<br>I don't have an objection to an attribute that effectively makes=20
<br>implicit fallthrough an error for a particular switch (i.e. your=20
<br>'[[safe]]' attribute, above). I have a preference for annotating the=20
<br>actual occurrence of intended fallthrough versus disabling the=20
<br>diagnostic entirely for a particular switch (either way you're changing=
=20
<br>the code, but the explicit fallthrough is a better expression of=20
<br>intent), but would be okay having both options available.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_774_29834125.1389654613183--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Mon, 13 Jan 2014 22:15:46 -0800 (PST)
Raw View
------=_Part_4249_5690169.1389680146751
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 14, 2014 12:10:13 AM UTC+1, Bengt Gustafsson wrote:
>
> disallow goto loops, as they are more often than not bugs.
I am not sure I follow what you are suggesting. Currently (without the
proposal) you can create loops with jump statements (as well as iteration
statements or function recursion). This doesn't change under the proposal,
the only thing that changes is that rather than the goto target being just
the identifier labeled-statements it can also be the other two types of
labeled-statements ("case expr : stmt" and "default: stmt"), and possibly a
couple of additional points. These new targets can all be expressed now
(without the proposal) by introducing an identifier label at the target and
issuing a goto statement to that label:
For example, without the proposal today you can write this:
switch_stmt:
switch (condition)
{
case_foo:
case foo:
...
goto case_bar;
case_bar:
case bar:
...
goto case_foo;
case_baz:
case baz:
...
goto switch_stmt;
}
The available options for flow topology do not change in any significant
way. All the goto case statement part of the proposal does is save
polluting the function scope with these new labels when we can bind
directly to them using the case, default and switch keywords to bind the
target directly.
Perhaps it would help if you can provide an example of such a bug that is
possible or easier to make under the proposal than they are today? As far
as I can see this goto loop issue has nothing to do with the proposal.
I have previously suggested to allow multilevel break using the syntax
> "break break;"
As for "break break" to mean break out and then break out again. I think
this binds too weakly. Saying break out of the second smallest enclosing
scope is brittle because you are binding by order number, which can change
as the code changes. It is better to explicitly say I want to break out of
a specific named statement. This also follows the natural language grammar
"verb noun".
If we were going to extend the jump statements even further than so far
suggested it would be an additional proposal (the goto case statement is
only tied to explicit switch as a general replacement for fallthrough).
My current thought about this would be as a first move to copy Java and
have:
outer: for (int i = 0; i < 10; i++) {
while (true) {
break outer;
} }
In C++ terms that would be to add an additional jump statement "break
<identifier>" which jumps to the end of the named enclosing
labeled-statement.
As a second orthogonal move thereafter we could then add jump targets to
both goto and break simulatenously as follows:
jump-target:
identifier
case expr
default
if
while
switch
do
for
jump-statement:
goto jump-target_opt ;
break jump-target_opt;
continue ;
return expression_opt ;
return braced-init-list ;
For "identifier", "case expr" and "default" it describes that labeled
statement, for "if", "while", "switch", "do" and "for" it describes the
smallest enclosing statement that starts with that keyword. goto means
jump to the start of that statement. break means jump to the end.
--
---
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_4249_5690169.1389680146751
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, January 14, 2014 12:10:13 AM UTC+1, Bengt Gust=
afsson wrote:<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></blockquo=
te><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bo=
rder-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-st=
yle: solid; padding-left: 1ex;">disallow goto loops, as they are more often=
than not bugs.</blockquote><div><br></div><div>I am not sure I follow what=
you are suggesting. Currently (without the proposal) you can create =
loops with jump statements (as well as iteration statements or function rec=
ursion). This doesn't change under the proposal, the only thing that =
changes is that rather than the goto target being just the identifier label=
ed-statements it can also be the other two types of labeled-statements ("ca=
se expr : stmt" and "default: stmt"), and possibly a couple of additional p=
oints. These new targets can all be expressed now (without the propos=
al) by introducing an identifier label at the target and issuing a goto sta=
tement to that label:</div><div><br></div><div>For example, without the pro=
posal today you can write this:</div><div><br></div><div> swit=
ch_stmt:</div><div> switch (condition)</div><div> =
{</div><div> case_foo:</div><div> case foo:</div=
><div> ...</div><div> =
goto case_bar;</div><div><br></div><div> case_bar:</div><div>=
case bar:</div><div> ...</div><div=
> goto case_foo;</div><div><br></div><div> =
case_baz:</div><div> case baz:</div><div> =
...</div><div> goto switch_stmt;<=
/div><div> }</div><div><br></div><div>The available options fo=
r flow topology do not change in any significant way. All the goto ca=
se statement part of the proposal does is save polluting the function scope=
with these new labels when we can bind directly to them using the case, de=
fault and switch keywords to bind the target directly.<br></div><div><br></=
div><div>Perhaps it would help if you can provide an example of such a bug =
that is possible or easier to make under the proposal than they are today? =
As far as I can see this goto loop issue has nothing to do with the p=
roposal.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204,=
204, 204); border-left-style: solid; padding-left: 1ex;">I have previously=
suggested to allow multilevel break using the syntax "break break;"</block=
quote><div><br></div><div>As for "break break" to mean break out and then b=
reak out again. I think this binds too weakly. Saying break out=
of the second smallest enclosing scope is brittle because you are binding =
by order number, which can change as the code changes. It is better t=
o explicitly say I want to break out of a specific named statement. T=
his also follows the natural language grammar "verb noun".</div><div><br></=
div><div>If we were going to extend the jump statements even further than s=
o far suggested it would be an additional proposal (the goto case statement=
is only tied to explicit switch as a general replacement for fallthrough).=
</div><div><br></div><div>My current thought about this would be as a first=
move to copy Java and have:</div><div><br></div><div><pre class=3D"de1" st=
yle=3D"font-family: monospace, monospace; border-style: none; border-color:=
white; color: rgb(0, 0, 0); background-color: rgb(249, 249, 249); line-hei=
ght: 1.2em; background-image: none; vertical-align: top;"> outer:
<span class=3D"kw1" style=3D"font-weight: bold;"> for</span> <span class=
=3D"br0" style=3D"color: rgb(0, 153, 0);">(</span><span class=3D"kw3" style=
=3D"color: rgb(0, 102, 0); font-weight: bold;">int</span> i =3D <span class=
=3D"nu0" style=3D"color: rgb(204, 102, 204);">0</span><span class=3D"sy0" s=
tyle=3D"color: rgb(51, 153, 51);">;</span> i <span class=3D"sy0" style=3D"c=
olor: rgb(51, 153, 51);"><</span> <span class=3D"nu0" style=3D"color: rg=
b(204, 102, 204);">10</span><span class=3D"sy0" style=3D"color: rgb(51, 153=
, 51);">;</span> i++<span class=3D"br0" style=3D"color: rgb(0, 153, 0);">)<=
/span> <span class=3D"br0" style=3D"color: rgb(0, 153, 0);">{</span>
<span class=3D"kw1" style=3D"font-weight: bold;">while</span> <span=
class=3D"br0" style=3D"color: rgb(0, 153, 0);">(</span><span class=3D"kw4"=
style=3D"color: rgb(0, 102, 0); font-weight: bold;">true</span><span class=
=3D"br0" style=3D"color: rgb(0, 153, 0);">)</span> <span class=3D"br0" styl=
e=3D"color: rgb(0, 153, 0);">{</span>
<span class=3D"kw2" style=3D"font-weight: bold;">break</span> ou=
ter<span class=3D"sy0" style=3D"color: rgb(51, 153, 51);">;</span>
<span class=3D"br0" style=3D"color: rgb(0, 153, 0);">}</span>
<span class=3D"br0" style=3D"color: rgb(0, 153, 0);"> }</span></pre></di=
v><div><br></div><div>In C++ terms that would be to add an additional jump =
statement "break <identifier>" which jumps to the end of the named en=
closing labeled-statement.</div><div><br></div><div>As a second orthogonal =
move thereafter we could then add jump targets to both goto and break simul=
atenously as follows:</div><div><br></div><div><font face=3D"courier new, m=
onospace"> jump-target:</font></div><div><font face=3D"courier=
new, monospace"> identifier</font></div><div><f=
ont face=3D"courier new, monospace"> case expr</=
font></div><div><font face=3D"courier new, monospace"> =
default</font></div><div><font face=3D"courier new, monospace"> =
; if</font></div><div><font face=3D"courier new, monos=
pace"> while</font></div><div><font face=3D"cour=
ier new, monospace"> switch</font></div><div><fo=
nt face=3D"courier new, monospace"> do</font></d=
iv><div><font face=3D"courier new, monospace"> f=
or</font></div><div><font face=3D"courier new, monospace"><br></font></div>=
<div><div><font face=3D"courier new, monospace"> jump-statemen=
t:</font></div><div><font face=3D"courier new, monospace"> &nb=
sp; goto jump-target_opt ;</font></div><div><font face=3D"courier ne=
w, monospace"> break jump-target_opt;</font></di=
v><div><font face=3D"courier new, monospace"> co=
ntinue ;</font></div><div><font face=3D"courier new, monospace"> &nbs=
p; return expression_opt ;</font></div><div><font face=3D"cou=
rier new, monospace"> return braced-init-list ;<=
/font></div><div><br></div></div><div>For "identifier", "case expr" and "de=
fault" it describes that labeled statement, for "if", "while", "switch", "d=
o" and "for" it describes the smallest enclosing statement that starts with=
that keyword. goto means jump to the start of that statement. =
break means jump to the end.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4249_5690169.1389680146751--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 14 Jan 2014 14:37:58 +0800
Raw View
On 1/14/14 2:15 PM, Andrew Tomazos wrote:
> On Tuesday, January 14, 2014 12:10:13 AM UTC+1, Bengt Gustafsson wrote:
>> disallow goto loops, as they are more often than not bugs.
>
> I am not sure I follow what you are suggesting.
It sounds like he's requesting static analysis to stop the user from
implementing a loop using goto statements. However, this is essentially
impossible because the compiler does not statically know the runtime
control flow: a fully-connected network of basic blocks that
conditionally goto each other might never loop at all. Only endless
loops could reasonably be diagnosed, and such a program will misbehave
on the first test run anyway.
Anyway, "more often than not" is not a reason to make something illegal.
If there's a bug, that's what you get for playing with goto. If folks
still exist who don't know the danger, they aren't the ones the the
language should be designed for.
> My current thought about this would be as a first move to copy Java and
> have:
>
> outer: for (int i = 0; i < 10; i++) {
> while (true) {
> break outer;
> } }
>
>
> In C++ terms that would be to add an additional jump statement "break
> <identifier>" which jumps to the end of the named enclosing
> labeled-statement.
Hear, hear! It's embarrassing that Java has had this for so long.
> As a second orthogonal move thereafter we could then add jump targets to
> both goto and break simulatenously as follows:
>
> jump-target:
> identifier
> case expr
> default
> if
> while
> switch
> do
> for
>
> jump-statement:
> goto jump-target_opt ;
> break jump-target_opt;
> continue ;
> return expression_opt ;
> return braced-init-list ;
>
> For "identifier", "case expr" and "default" it describes that labeled
> statement, for "if", "while", "switch", "do" and "for" it describes the
> smallest enclosing statement that starts with that keyword. goto means
> jump to the start of that statement. break means jump to the end.
From the earlier part of the message I thought goto case expr; (and
presumably goto default;) was already proposed to be added first?
"Break if" sounds like bad news. Cases that are written as such should
not be done in shorthand; the end of the if-block should be explicitly
labeled. It would simplify macro metaprogramming by eliminating the need
to generate unique labels, but I've never heard anyone complain about that.
Likewise "break for;" is even more brittle than simply "break;" because
it is affected if the enclosing loop is refactored to another form.
"break identifier;" is great because it's so explicit and unambiguously
self-explanatory.
Also, the grammar appears to be missing continue statements for named loops.
--
---
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: Mon, 13 Jan 2014 22:52:26 -0800 (PST)
Raw View
------=_Part_1611_19122264.1389682346049
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, January 14, 2014 7:37:58 AM UTC+1, David Krauss wrote:
>
> From the earlier part of the message I thought goto case expr; (and
> presumably goto default;) was already proposed to be added first?
>
That is correct. The goto case statement (which includes goto default) are
definitely part of the safe explicit switch proposal as they replace
fallthrough.
The full set of extensions to the jump statement in my previous message are
in addition to them, and would be part of a separate proposal "Jump
Statement Extensions" or something like that.
Both proposals are compatible, and can be applied in either order.
--
---
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_1611_19122264.1389682346049
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, January 14, 2014 7:37:58 AM UTC+1, David Kraus=
s wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> From the earlier=
part of the message I thought goto case expr; (and=20
<br>presumably goto default;) was already proposed to be added first?
<br>
</blockquote><div><br></div><div>That is correct. The goto case state=
ment (which includes goto default) are definitely part of the safe explicit=
switch proposal as they replace fallthrough.</div><div><br></div><div>The =
full set of extensions to the jump statement in my previous message are in =
addition to them, and would be part of a separate proposal "Jump Statement =
Extensions" or something like that.</div><div><br></div><div>Both proposals=
are compatible, and can be applied in either order.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1611_19122264.1389682346049--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 14 Jan 2014 11:51:31 -0500
Raw View
On 2014-01-14 01:15, Andrew Tomazos wrote:
> As a second orthogonal move thereafter we could then add jump targets to
> both goto and break simulatenously as follows:
>
> jump-target:
> identifier
> case expr
> default
> if
> while
> switch
> do
> for
>
> jump-statement:
> goto jump-target_opt ;
> break jump-target_opt;
> continue ;
> return expression_opt ;
> return braced-init-list ;
Shouldn't 'continue' also accept a jump-target_opt?
e.g. (braces elided):
A: for (a : list_a)
B: for (b : list_b)
if (cond)
continue A; // done with B loop but not A loop
--
Matthew
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Tue, 14 Jan 2014 13:45:28 -0800 (PST)
Raw View
------=_Part_520_24350566.1389735928613
Content-Type: text/plain; charset=UTF-8
When it comes to the goto switch and goto <expression> forms I just wanted
to say that we don't need them as they promote non-structured programming
styles for which we already have one construct too many: goto. And that
goto can easily be used for these cases (in the latter form using a
temporary variable to be able to insert a new expression into the switch)
if you really insist on implementing a loop with a switch but no looping
statement.
I like the idea of a break <label>; and continue <label>; better than my
own break break idea. I don't like the break for/while/switch/do; idea as
it doesn't solve the problem of exiting two nested for loops, which is
probably the most common case. Also it is as brittle as break break; (if
you change loop type and there is another one further out). I didn't know
of this rather elegant Java solution.
Regarding the original safe switch I suggest using the continue keyword
instead of goto as you don't have to qualify with a "case" keyword to
disambiguate, and as the goto keyword remains as the warning beacon for
ugly coding it is today.
Thus:
- A case in an explicit switch statement normally exits the switch
statement when finished.
- Inside a case you can write continue <case label>; or continue default;
to "fall" to another case. A plain continue; still continues the closest
surrounding loop for backwards compatiblity (or maybe not? -- this is a new
switch statement after all).
I suggest that such continues can only continue forwards, to succeding
cases. This would prevent loops from forming while allowing all
combinations of cases (I think) that run in succession once. The compiler
can easily check this.
You may argue that continue "normally" continues by going backwards to the
start of a loop. I would counter that in the normal English meaning it is
more logical to continue forwards, and that it is also logical that switch
statements continue forwards while loops continue by going back.
It would even be thinkable to let just continue; in a safe switch mean
"continue with the next case" as this implements the basic intention of the
"safe switch": to make fall through an explicitly called for possibility
rather than the default behaviour. I would even be satisfied if this was
the only new possibility for a "safe switch": Instead of using break to get
out after a case you use continue not to!
Sorry if this came out in a confusing way, but I don't have time for more
editing right now.
Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skrev Matthew Woehlke:
>
> On 2014-01-14 01:15, Andrew Tomazos wrote:
> > As a second orthogonal move thereafter we could then add jump targets to
> > both goto and break simulatenously as follows:
> >
> > jump-target:
> > identifier
> > case expr
> > default
> > if
> > while
> > switch
> > do
> > for
> >
> > jump-statement:
> > goto jump-target_opt ;
> > break jump-target_opt;
> > continue ;
> > return expression_opt ;
> > return braced-init-list ;
>
> Shouldn't 'continue' also accept a jump-target_opt?
>
> e.g. (braces elided):
>
> A: for (a : list_a)
> B: for (b : list_b)
> if (cond)
> continue A; // done with B loop but not A loop
>
> --
> 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/.
------=_Part_520_24350566.1389735928613
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>When it comes to the goto switch and goto <express=
ion> forms I just wanted to say that we don't need them as they promote =
non-structured programming styles for which we already have one construct t=
oo many: goto. And that goto can easily be used for these cases (in the lat=
ter form using a temporary variable to be able to insert a new expression i=
nto the switch) if you really insist on implementing a loop with a switch b=
ut no looping statement.</div><div><br></div>I like the idea of a break <=
;label>; and continue <label>; better than my own break break idea=
.. I don't like the break for/while/switch/do; idea as it doesn't solve the =
problem of exiting two nested for loops, which is probably the most common =
case. Also it is as brittle as break break; (if you change loop type and th=
ere is another one further out). I didn't know of this rather elegant Java =
solution.<div><br></div><div>Regarding the original safe switch I suggest u=
sing the continue keyword instead of goto as you don't have to qualify with=
a "case" keyword to disambiguate, and as the goto keyword remains as the w=
arning beacon for ugly coding it is today.</div><div><br></div><div>Thus:</=
div><div><br></div><div>- A case in an explicit switch statement normally e=
xits the switch statement when finished.</div><div>- Inside a case you can =
write continue <case label>; or continue default; to "fall" to anothe=
r case. A plain continue; still continues the closest surrounding loop for =
backwards compatiblity (or maybe not? -- this is a new switch statement aft=
er all).</div><div><br></div><div>I suggest that such continues can only co=
ntinue forwards, to succeding cases. This would prevent loops from forming =
while allowing all combinations of cases (I think) that run in succession o=
nce. The compiler can easily check this.</div><div><br><div>You may argue t=
hat continue "normally" continues by going backwards to the start of a loop=
.. I would counter that in the normal English meaning it is more logical to =
continue forwards, and that it is also logical that switch statements conti=
nue forwards while loops continue by going back.</div><div><br></div><div>I=
t would even be thinkable to let just continue; in a safe switch mean "cont=
inue with the next case" as this implements the basic intention of the "saf=
e switch": to make fall through an explicitly called for possibility rather=
than the default behaviour. I would even be satisfied if this was the only=
new possibility for a "safe switch": Instead of using break to get out aft=
er a case you use continue not to!</div><div><br></div><div>Sorry if this c=
ame out in a confusing way, but I don't have time for more editing right no=
w.</div><div><br>Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skre=
v Matthew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-01-1=
4 01:15, Andrew Tomazos wrote:
<br>> As a second orthogonal move thereafter we could then add jump targ=
ets to
<br>> both goto and break simulatenously as follows:
<br>>
<br>> jump-target:
<br>> identifier
<br>> case expr
<br>> default
<br>> if
<br>> while
<br>> switch
<br>> do
<br>> for
<br>>
<br>> jump-statement:
<br>> goto jump-target_opt ;
<br>> break jump-target_opt;
<br>> continue ;
<br>> return expression_opt ;
<br>> return braced-init-list ;
<br>
<br>Shouldn't 'continue' also accept a jump-target_opt?
<br>
<br>e.g. (braces elided):
<br>
<br>A: for (a : list_a)
<br> B: for (b : list_b)
<br> if (cond)
<br> continue A; // done with B loop but not A lo=
op
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_520_24350566.1389735928613--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Tue, 14 Jan 2014 21:31:51 -0800 (PST)
Raw View
------=_Part_4851_25622801.1389763911046
Content-Type: text/plain; charset=UTF-8
- In Java the scope of an identifier label is only that statement, whereas
in C++ it is the entire function scope. This is because Java dropped goto
statements. So while I propose "break <label>;", I also think it would be
useful to be able to target the smallest enclosing statement of a
particular statement category ("break for;", "break while;", etc) without
introducing a label. This allows the programmer to make the tradeoff
between introducing a name into the entire function scope, and risking a
change of binding if the code is updated to change the target statement
category. You can always ban one or both ways in your coding guidelines.
- Yes "continue jump-target_opt" was accidentally omitted. The semantics
of "continue jump-statement" are the same w.r.t. well-formedness and
meaning as "continue" is except the subject statement is explicitly
specified by the jump-target and not the smallest enclosing one for which
it applies. This is the same as the relationship between "break
jump-target" and "break".
So this means the following are all always ill-formed:
break if;
continue if;
continue switch;
- "goto jump-target_opt" was accidentally optional. It isn't. ("goto;" is
ill-formed) It should be just "goto jump-target".
- From a structured programming point-of-view, fallthrough is the same as a
goto case statement (except worse when unbound or implicit). It doesn't
matter that fallthrough can only occur between two lexically consecutive
cases in the source. Fallthrough isn't a "structured" feature, nor was it
ever intended to be. It was only available because in the dumb translation
of a switch statement into assembly code, fallthrough was high performance
- you literally let the CPU "fallthrough" into the next case statement
because the machine code happens to be at that next address in memory. If
you don't like goto statements and think they are ugly, under the proposal,
you can simply keep the requirement "goto is banned" in your coding
guidelines, and just add "all switch statements must be
explicit-specified". This will mean you have banned fallthrough as well
because it isn't structured programming.
> using continue keyword instead of goto as you don't have to qualify with
a "case" keyword to disambiguate
I would prefer to keep compatibility between the proposal and the existing
C# practice. The syntax and semantics of what I am proposing have already
been thoroughly tested by that community. On top of that I think it is
better to use "goto" as it lets people know it is a jump in the same
category as a goto statement. It is also more elegant and lower complexity
from a specification point-of-view.
> A case in an explicit switch statement normally exits the switch
statement when finished.
I didn't follow this. If it is possible to flow off the end of a case
block in an explicit-specified switch, the program is ill-formed. In a
non-explicit-specified switch, it causes an implicit fallthrough to the
next case.
> Inside a case you can write continue <case label>; or continue default;
to "fall" to another case. A plain continue; still continues the closest
surrounding loop for backwards compatiblity (or maybe not? -- this is a new
switch statement after all).
I think I'll be proposing "goto case <expr>" and "goto default", same as C#
for reasons above. If nothing else than the existing practice should be
convincing. C# is in the top 5 most used languages today.
A plain "continue;" means the same in an explicit-specified switch as it
does in a non-explicit-specified switch. The proposal has a design rule
which is that adding or removing the explicit specifier to a switch
statement can have no effect other than making the statement ill-formed or
well-formed. It never changes the semantic meaning. For "continue;" to
mean something different would violate that.
> It would even be thinkable to let just continue; in a safe switch mean
"continue with the next case" as this implements the basic intention of the
"safe switch": to make fall through an explicitly called for possibility
rather than the default behaviour. I would even be satisfied if this was
the only new possibility for a "safe switch": Instead of using break to get
out after a case you use continue not to!
It's too late for that. Everyone terminates cases with break, and uses
continue to repeat an enclosing iteration statement. The proposal doesn't
change that, it just makes implicit fallthrough ill-formed in an
explicit-specified switch (and a couple of other little tweaks). For 97%
of uses everything else is the same, the only difference is that your
implicit fallthrough bugs will be caught and you don't have to surround
case blocks in a compound statement to declare a local variable in the case
block.
On Tuesday, January 14, 2014 10:45:28 PM UTC+1, Bengt Gustafsson wrote:
>
> When it comes to the goto switch and goto <expression> forms I just wanted
> to say that we don't need them as they promote non-structured programming
> styles for which we already have one construct too many: goto. And that
> goto can easily be used for these cases (in the latter form using a
> temporary variable to be able to insert a new expression into the switch)
> if you really insist on implementing a loop with a switch but no looping
> statement.
>
> I like the idea of a break <label>; and continue <label>; better than my
> own break break idea. I don't like the break for/while/switch/do; idea as
> it doesn't solve the problem of exiting two nested for loops, which is
> probably the most common case. Also it is as brittle as break break; (if
> you change loop type and there is another one further out). I didn't know
> of this rather elegant Java solution.
>
> Regarding the original safe switch I suggest using the continue keyword
> instead of goto as you don't have to qualify with a "case" keyword to
> disambiguate, and as the goto keyword remains as the warning beacon for
> ugly coding it is today.
>
> Thus:
>
> - A case in an explicit switch statement normally exits the switch
> statement when finished.
> - Inside a case you can write continue <case label>; or continue default;
> to "fall" to another case. A plain continue; still continues the closest
> surrounding loop for backwards compatiblity (or maybe not? -- this is a new
> switch statement after all).
>
> I suggest that such continues can only continue forwards, to succeding
> cases. This would prevent loops from forming while allowing all
> combinations of cases (I think) that run in succession once. The compiler
> can easily check this.
>
> You may argue that continue "normally" continues by going backwards to the
> start of a loop. I would counter that in the normal English meaning it is
> more logical to continue forwards, and that it is also logical that switch
> statements continue forwards while loops continue by going back.
>
> It would even be thinkable to let just continue; in a safe switch mean
> "continue with the next case" as this implements the basic intention of the
> "safe switch": to make fall through an explicitly called for possibility
> rather than the default behaviour. I would even be satisfied if this was
> the only new possibility for a "safe switch": Instead of using break to get
> out after a case you use continue not to!
>
> Sorry if this came out in a confusing way, but I don't have time for more
> editing right now.
>
> Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skrev Matthew
> Woehlke:
>>
>> On 2014-01-14 01:15, Andrew Tomazos wrote:
>> > As a second orthogonal move thereafter we could then add jump targets
>> to
>> > both goto and break simulatenously as follows:
>> >
>> > jump-target:
>> > identifier
>> > case expr
>> > default
>> > if
>> > while
>> > switch
>> > do
>> > for
>> >
>> > jump-statement:
>> > goto jump-target_opt ;
>> > break jump-target_opt;
>> > continue ;
>> > return expression_opt ;
>> > return braced-init-list ;
>>
>> Shouldn't 'continue' also accept a jump-target_opt?
>>
>> e.g. (braces elided):
>>
>> A: for (a : list_a)
>> B: for (b : list_b)
>> if (cond)
>> continue A; // done with B loop but not A loop
>>
>> --
>> 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/.
------=_Part_4851_25622801.1389763911046
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">- In Java the scope of an identifier label is only that st=
atement, whereas in C++ it is the entire function scope. This is beca=
use Java dropped goto statements. So while I propose "break <label=
>;", I also think it would be useful to be able to target the smallest e=
nclosing statement of a particular statement category ("break for;", "break=
while;", etc) without introducing a label. This allows the programme=
r to make the tradeoff between introducing a name into the entire function =
scope, and risking a change of binding if the code is updated to change the=
target statement category. You can always ban one or both ways in yo=
ur coding guidelines.<div><div><br></div><div>- Yes "continue jump-target_o=
pt" was accidentally omitted. The semantics of "continue jump-stateme=
nt" are the same w.r.t. well-formedness and meaning as "continue" is except=
the subject statement is explicitly specified by the jump-target and not t=
he smallest enclosing one for which it applies. This is the same as t=
he relationship between "break jump-target" and "break".</div><div><br></di=
v><div>So this means the following are all always ill-formed:</div><div><br=
></div><div> break if;</div><div> continue if;</d=
iv><div> continue switch;</div><div><br></div><div>- "goto jum=
p-target_opt" was accidentally optional. It isn't. ("goto;" is =
ill-formed) It should be just "goto jump-target".</div><div><br></div=
><div>- From a structured programming point-of-view, fallthrough is the sam=
e as a goto case statement (except worse when unbound or implicit). I=
t doesn't matter that fallthrough can only occur between two lexically cons=
ecutive cases in the source. Fallthrough isn't a "structured" feature=
, nor was it ever intended to be. It was only available because in th=
e dumb translation of a switch statement into assembly code, fallthrough wa=
s high performance - you literally let the CPU "fallthrough" into the next =
case statement because the machine code happens to be at that next address =
in memory. If you don't like goto statements and think they are ugly,=
under the proposal, you can simply keep the requirement "goto is banned" i=
n your coding guidelines, and just add "all switch statements must be expli=
cit-specified". This will mean you have banned fallthrough as well be=
cause it isn't structured programming.</div><div><br></div><div>> using =
continue keyword instead of goto as you don't have to qualify with a "case"=
keyword to disambiguate<br></div><div><br></div><div>I would prefer to kee=
p compatibility between the proposal and the existing C# practice. Th=
e syntax and semantics of what I am proposing have already been thoroughly =
tested by that community. On top of that I think it is better to use =
"goto" as it lets people know it is a jump in the same category as a goto s=
tatement. It is also more elegant and lower complexity from a specifi=
cation point-of-view.</div><div><br></div><div>> A case in an explicit s=
witch statement normally exits the switch statement when finished.<br></div=
><div><br></div><div>I didn't follow this. If it is possible to flow =
off the end of a case block in an explicit-specified switch, the program is=
ill-formed. In a non-explicit-specified switch, it causes an implici=
t fallthrough to the next case.</div><div><br></div><div>> Inside a case=
you can write continue <case label>; or continue default; to "fall" =
to another case. A plain continue; still continues the closest surrounding =
loop for backwards compatiblity (or maybe not? -- this is a new switch stat=
ement after all).</div><div><br></div><div>I think I'll be proposing "goto =
case <expr>" and "goto default", same as C# for reasons above. =
If nothing else than the existing practice should be convincing. C# i=
s in the top 5 most used languages today.</div><div><br></div><div>A plain =
"continue;" means the same in an explicit-specified switch as it does in a =
non-explicit-specified switch. The proposal has a design rule which i=
s that adding or removing the explicit specifier to a switch statement can =
have no effect other than making the statement ill-formed or well-formed. &=
nbsp;It never changes the semantic meaning. For "continue;" to mean s=
omething different would violate that. </div><div><br></div><div>>=
It would even be thinkable to let just continue; in a safe switch mean "co=
ntinue with the next case" as this implements the basic intention of the "s=
afe switch": to make fall through an explicitly called for possibility rath=
er than the default behaviour. I would even be satisfied if this was the on=
ly new possibility for a "safe switch": Instead of using break to get out a=
fter a case you use continue not to!</div><div><br></div><div>It's too late=
for that. Everyone terminates cases with break, and uses continue to=
repeat an enclosing iteration statement. The proposal doesn't change=
that, it just makes implicit fallthrough ill-formed in an explicit-specifi=
ed switch (and a couple of other little tweaks). For 97% of uses ever=
ything else is the same, the only difference is that your implicit fallthro=
ugh bugs will be caught and you don't have to surround case blocks in a com=
pound statement to declare a local variable in the case block.</div><div><b=
r></div><div><br></div><div>On Tuesday, January 14, 2014 10:45:28 PM UTC+1,=
Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div>When it comes to the goto switch and goto <expression>=
; forms I just wanted to say that we don't need them as they promote non-st=
ructured programming styles for which we already have one construct too man=
y: goto. And that goto can easily be used for these cases (in the latter fo=
rm using a temporary variable to be able to insert a new expression into th=
e switch) if you really insist on implementing a loop with a switch but no =
looping statement.</div><div><br></div>I like the idea of a break <label=
>; and continue <label>; better than my own break break idea. I do=
n't like the break for/while/switch/do; idea as it doesn't solve the proble=
m of exiting two nested for loops, which is probably the most common case. =
Also it is as brittle as break break; (if you change loop type and there is=
another one further out). I didn't know of this rather elegant Java soluti=
on.<div><br></div><div>Regarding the original safe switch I suggest using t=
he continue keyword instead of goto as you don't have to qualify with a "ca=
se" keyword to disambiguate, and as the goto keyword remains as the warning=
beacon for ugly coding it is today.</div><div><br></div><div>Thus:</div><d=
iv><br></div><div>- A case in an explicit switch statement normally exits t=
he switch statement when finished.</div><div>- Inside a case you can write =
continue <case label>; or continue default; to "fall" to another case=
.. A plain continue; still continues the closest surrounding loop for backwa=
rds compatiblity (or maybe not? -- this is a new switch statement after all=
).</div><div><br></div><div>I suggest that such continues can only continue=
forwards, to succeding cases. This would prevent loops from forming while =
allowing all combinations of cases (I think) that run in succession once. T=
he compiler can easily check this.</div><div><br><div>You may argue that co=
ntinue "normally" continues by going backwards to the start of a loop. I wo=
uld counter that in the normal English meaning it is more logical to contin=
ue forwards, and that it is also logical that switch statements continue fo=
rwards while loops continue by going back.</div><div><br></div><div>It woul=
d even be thinkable to let just continue; in a safe switch mean "continue w=
ith the next case" as this implements the basic intention of the "safe swit=
ch": to make fall through an explicitly called for possibility rather than =
the default behaviour. I would even be satisfied if this was the only new p=
ossibility for a "safe switch": Instead of using break to get out after a c=
ase you use continue not to!</div><div><br></div><div>Sorry if this came ou=
t in a confusing way, but I don't have time for more editing right now.</di=
v><div><br>Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skrev Matt=
hew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-01-14 01:15, An=
drew Tomazos wrote:
<br>> As a second orthogonal move thereafter we could then add jump targ=
ets to
<br>> both goto and break simulatenously as follows:
<br>>
<br>> jump-target:
<br>> identifier
<br>> case expr
<br>> default
<br>> if
<br>> while
<br>> switch
<br>> do
<br>> for
<br>>
<br>> jump-statement:
<br>> goto jump-target_opt ;
<br>> break jump-target_opt;
<br>> continue ;
<br>> return expression_opt ;
<br>> return braced-init-list ;
<br>
<br>Shouldn't 'continue' also accept a jump-target_opt?
<br>
<br>e.g. (braces elided):
<br>
<br>A: for (a : list_a)
<br> B: for (b : list_b)
<br> if (cond)
<br> continue A; // done with B loop but not A lo=
op
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div></div></blockquote></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_4851_25622801.1389763911046--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 15 Jan 2014 10:16:52 -0800 (PST)
Raw View
------=_Part_450_8666043.1389809812051
Content-Type: text/plain; charset=UTF-8
Den onsdagen den 15:e januari 2014 kl. 06:31:51 UTC+1 skrev Andrew Tomazos:
>
> - In Java the scope of an identifier label is only that statement, whereas
> in C++ it is the entire function scope. This is because Java dropped goto
> statements. So while I propose "break <label>;", I also think it would be
> useful to be able to target the smallest enclosing statement of a
> particular statement category ("break for;", "break while;", etc) without
> introducing a label. This allows the programmer to make the tradeoff
> between introducing a name into the entire function scope, and risking a
> change of binding if the code is updated to change the target statement
> category. You can always ban one or both ways in your coding guidelines.
>
I think I would.
>
> - Yes "continue jump-target_opt" was accidentally omitted. The semantics
> of "continue jump-statement" are the same w.r.t. well-formedness and
> meaning as "continue" is except the subject statement is explicitly
> specified by the jump-target and not the smallest enclosing one for which
> it applies. This is the same as the relationship between "break
> jump-target" and "break".
>
> So this means the following are all always ill-formed:
>
> break if;
> continue if;
> continue switch;
>
> - "goto jump-target_opt" was accidentally optional. It isn't. ("goto;"
> is ill-formed) It should be just "goto jump-target".
>
> - From a structured programming point-of-view, fallthrough is the same as
> a goto case statement (except worse when unbound or implicit). It doesn't
> matter that fallthrough can only occur between two lexically consecutive
> cases in the source. Fallthrough isn't a "structured" feature, nor was it
> ever intended to be. It was only available because in the dumb translation
> of a switch statement into assembly code, fallthrough was high performance
> - you literally let the CPU "fallthrough" into the next case statement
> because the machine code happens to be at that next address in memory. If
> you don't like goto statements and think they are ugly, under the proposal,
> you can simply keep the requirement "goto is banned" in your coding
> guidelines, and just add "all switch statements must be
> explicit-specified". This will mean you have banned fallthrough as well
> because it isn't structured programming.
>
Well, maybe, allowing explicit continuations but only forwards is however
quite easy to read compared to a mess of gotos, and you can know that there
are no hidden loops.
> > using continue keyword instead of goto as you don't have to qualify with
> a "case" keyword to disambiguate
>
> I would prefer to keep compatibility between the proposal and the existing
> C# practice. The syntax and semantics of what I am proposing have already
> been thoroughly tested by that community. On top of that I think it is
> better to use "goto" as it lets people know it is a jump in the same
> category as a goto statement. It is also more elegant and lower complexity
> from a specification point-of-view.
>
>
> > A case in an explicit switch statement normally exits the switch
> statement when finished.
>
> I didn't follow this. If it is possible to flow off the end of a case
> block in an explicit-specified switch, the program is ill-formed. In a
> non-explicit-specified switch, it causes an implicit fallthrough to the
> next case.
>
So you mean that you will demand that there'd be a redundant break after
each case. I see your point about allowing the addition of "explicit" but I
don't know if this is a strong enough argument. I mean you can take the
view that it is most important to retrofit old code with the new 'explicit'
keyword or to optimize the utility of the explicit switch for new code.
After all, if you add 'explicit' to your code with a global replace most of
the instances of error diagnostics will NOT be bugs, but still require
attendance. For new code (before testing) a fair percentage of missing
breaks will be bugs, so it is here that the 'explicit' will improve the
situation the most. In fact, I can easliy imagine that if you add
'explicit' to old code as a campaign there will be a fair amount of
instances where the person doing the replacing will introduce new bugs by
not understanding if the fall through was intentional or a bug...
By this I want to say that maybe staying as close to the original switch as
possible may not be the best way to go. Now that I read my own sentence
above it actually seems most logical to unify with the other control
statements: Allow only one statement per case, if you want more use a block
statement.
(A side idea I have had for a while is to allow multi-dimensional switches,
i.e. switch (a ; b ; c) { case 1,2,3: code; case 1,1,1: code(); }. The idea
is basically useful to handle those ugly if-trees where you have a number
of disparate combinations requiring the same action. Today this either
requires code repitition or factoring into a function (which often needs to
have surprisingly many parameters)).
>
> > Inside a case you can write continue <case label>; or continue default;
> to "fall" to another case. A plain continue; still continues the closest
> surrounding loop for backwards compatiblity (or maybe not? -- this is a new
> switch statement after all).
>
> I think I'll be proposing "goto case <expr>" and "goto default", same as
> C# for reasons above. If nothing else than the existing practice should be
> convincing. C# is in the top 5 most used languages today.
>
That's a slightly more convincing argument. But not fully as C# doesn't
have the wild gotos of C++, so goto does not signify a warning sign as it
does in C++.
>
> A plain "continue;" means the same in an explicit-specified switch as it
> does in a non-explicit-specified switch. The proposal has a design rule
> which is that adding or removing the explicit specifier to a switch
> statement can have no effect other than making the statement ill-formed or
> well-formed. It never changes the semantic meaning. For "continue;" to
> mean something different would violate that.
>
See my reasoning about prioritites above.
>
>
> > It would even be thinkable to let just continue; in a safe switch mean
> "continue with the next case" as this implements the basic intention of the
> "safe switch": to make fall through an explicitly called for possibility
> rather than the default behaviour. I would even be satisfied if this was
> the only new possibility for a "safe switch": Instead of using break to get
> out after a case you use continue not to!
>
> It's too late for that. Everyone terminates cases with break, and uses
> continue to repeat an enclosing iteration statement. The proposal doesn't
> change that, it just makes implicit fallthrough ill-formed in an
> explicit-specified switch (and a couple of other little tweaks). For 97%
> of uses everything else is the same, the only difference is that your
> implicit fallthrough bugs will be caught and you don't have to surround
> case blocks in a compound statement to declare a local variable in the case
> block.
>
> ok, so you forbid variables from leaking into succeeding cases. I bet that
there are people finding ways to use that misfeature of the old switch,
especially those that create loops by using goto. How about the cleanup
actions needed when these variables are no longer in scope? Won't they be a
mandatory and error prone procedure when retrofitting 'explicit' to
switches? Maybe all compilers warn about this even for simple data types (I
know they do for variables with ctors). But warnings do get ignored or
pragma-removed...
Question remains: How many large code bases will see 'explciit'
retrofitting in reality? Is this important enough to make the new switch
less than optimal for new code?
> On Tuesday, January 14, 2014 10:45:28 PM UTC+1, Bengt Gustafsson wrote:
>>
>> When it comes to the goto switch and goto <expression> forms I just
>> wanted to say that we don't need them as they promote non-structured
>> programming styles for which we already have one construct too many: goto.
>> And that goto can easily be used for these cases (in the latter form using
>> a temporary variable to be able to insert a new expression into the switch)
>> if you really insist on implementing a loop with a switch but no looping
>> statement.
>>
>> I like the idea of a break <label>; and continue <label>; better than my
>> own break break idea. I don't like the break for/while/switch/do; idea as
>> it doesn't solve the problem of exiting two nested for loops, which is
>> probably the most common case. Also it is as brittle as break break; (if
>> you change loop type and there is another one further out). I didn't know
>> of this rather elegant Java solution.
>>
>> Regarding the original safe switch I suggest using the continue keyword
>> instead of goto as you don't have to qualify with a "case" keyword to
>> disambiguate, and as the goto keyword remains as the warning beacon for
>> ugly coding it is today.
>>
>> Thus:
>>
>> - A case in an explicit switch statement normally exits the switch
>> statement when finished.
>> - Inside a case you can write continue <case label>; or continue default;
>> to "fall" to another case. A plain continue; still continues the closest
>> surrounding loop for backwards compatiblity (or maybe not? -- this is a new
>> switch statement after all).
>>
>> I suggest that such continues can only continue forwards, to succeding
>> cases. This would prevent loops from forming while allowing all
>> combinations of cases (I think) that run in succession once. The compiler
>> can easily check this.
>>
>> You may argue that continue "normally" continues by going backwards to
>> the start of a loop. I would counter that in the normal English meaning it
>> is more logical to continue forwards, and that it is also logical that
>> switch statements continue forwards while loops continue by going back.
>>
>> It would even be thinkable to let just continue; in a safe switch mean
>> "continue with the next case" as this implements the basic intention of the
>> "safe switch": to make fall through an explicitly called for possibility
>> rather than the default behaviour. I would even be satisfied if this was
>> the only new possibility for a "safe switch": Instead of using break to get
>> out after a case you use continue not to!
>>
>> Sorry if this came out in a confusing way, but I don't have time for more
>> editing right now.
>>
>> Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skrev Matthew
>> Woehlke:
>>>
>>> On 2014-01-14 01:15, Andrew Tomazos wrote:
>>> > As a second orthogonal move thereafter we could then add jump targets
>>> to
>>> > both goto and break simulatenously as follows:
>>> >
>>> > jump-target:
>>> > identifier
>>> > case expr
>>> > default
>>> > if
>>> > while
>>> > switch
>>> > do
>>> > for
>>> >
>>> > jump-statement:
>>> > goto jump-target_opt ;
>>> > break jump-target_opt;
>>> > continue ;
>>> > return expression_opt ;
>>> > return braced-init-list ;
>>>
>>> Shouldn't 'continue' also accept a jump-target_opt?
>>>
>>> e.g. (braces elided):
>>>
>>> A: for (a : list_a)
>>> B: for (b : list_b)
>>> if (cond)
>>> continue A; // done with B loop but not A loop
>>>
>>> --
>>> 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/.
------=_Part_450_8666043.1389809812051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Den onsdagen den 15:e januari 2014 kl. 06:31:51 UT=
C+1 skrev Andrew Tomazos:<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">- In Java the scope of an identifier label is only that stateme=
nt, whereas in C++ it is the entire function scope. This is because J=
ava dropped goto statements. So while I propose "break <label>;=
", I also think it would be useful to be able to target the smallest enclos=
ing statement of a particular statement category ("break for;", "break whil=
e;", etc) without introducing a label. This allows the programmer to =
make the tradeoff between introducing a name into the entire function scope=
, and risking a change of binding if the code is updated to change the targ=
et statement category. You can always ban one or both ways in your co=
ding guidelines.</div></blockquote><div>I think I would. </div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><br></div>=
<div>- Yes "continue jump-target_opt" was accidentally omitted. The s=
emantics of "continue jump-statement" are the same w.r.t. well-formedness a=
nd meaning as "continue" is except the subject statement is explicitly spec=
ified by the jump-target and not the smallest enclosing one for which it ap=
plies. This is the same as the relationship between "break jump-targe=
t" and "break".</div><div><br></div><div>So this means the following are al=
l always ill-formed:</div><div><br></div><div> break if;</div>=
<div> continue if;</div><div> continue switch;</d=
iv><div><br></div><div>- "goto jump-target_opt" was accidentally optional. =
It isn't. ("goto;" is ill-formed) It should be just "goto=
jump-target".</div><div><br></div><div>- From a structured programming poi=
nt-of-view, fallthrough is the same as a goto case statement (except worse =
when unbound or implicit). It doesn't matter that fallthrough can onl=
y occur between two lexically consecutive cases in the source. Fallth=
rough isn't a "structured" feature, nor was it ever intended to be. I=
t was only available because in the dumb translation of a switch statement =
into assembly code, fallthrough was high performance - you literally let th=
e CPU "fallthrough" into the next case statement because the machine code h=
appens to be at that next address in memory. If you don't like goto s=
tatements and think they are ugly, under the proposal, you can simply keep =
the requirement "goto is banned" in your coding guidelines, and just add "a=
ll switch statements must be explicit-specified". This will mean you =
have banned fallthrough as well because it isn't structured programming.</d=
iv></div></div></blockquote><div>Well, maybe, allowing explicit continuatio=
ns but only forwards is however quite easy to read compared to a mess of go=
tos, and you can know that there are no hidden loops.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><br>=
</div><div>> using continue keyword instead of goto as you don't have to=
qualify with a "case" keyword to disambiguate<br></div><div><br></div><div=
>I would prefer to keep compatibility between the proposal and the existing=
C# practice. The syntax and semantics of what I am proposing have al=
ready been thoroughly tested by that community. On top of that I thin=
k it is better to use "goto" as it lets people know it is a jump in the sam=
e category as a goto statement. It is also more elegant and lower com=
plexity from a specification point-of-view.</div></div></div></blockquote><=
div> </div><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><div><br></div><div>> A case in an explicit switch statement nor=
mally exits the switch statement when finished.<br></div><div><br></div><di=
v>I didn't follow this. If it is possible to flow off the end of a ca=
se block in an explicit-specified switch, the program is ill-formed. =
In a non-explicit-specified switch, it causes an implicit fallthrough to th=
e next case.</div></div></div></blockquote><div>So you mean that you will d=
emand that there'd be a redundant break after each case. I see your point a=
bout allowing the addition of "explicit" but I don't know if this is a stro=
ng enough argument. I mean you can take the view that it is most important =
to retrofit old code with the new 'explicit' keyword or to optimize the uti=
lity of the explicit switch for new code. After all, if you add 'explicit' =
to your code with a global replace most of the instances of error diagnosti=
cs will NOT be bugs, but still require attendance. For new code (before tes=
ting) a fair percentage of missing breaks will be bugs, so it is here that =
the 'explicit' will improve the situation the most. In fact, I can easliy i=
magine that if you add 'explicit' to old code as a campaign there will be a=
fair amount of instances where the person doing the replacing will introdu=
ce new bugs by not understanding if the fall through was intentional or a b=
ug...</div><div><br></div><div>By this I want to say that maybe staying as =
close to the original switch as possible may not be the best way to go. Now=
that I read my own sentence above it actually seems most logical to unify =
with the other control statements: Allow only one statement per case, if yo=
u want more use a block statement.</div><div><br></div><div>(A side idea I =
have had for a while is to allow multi-dimensional switches, i.e. switch (a=
; b ; c) { case 1,2,3: code; case 1,1,1: code(); }. The idea is basically =
useful to handle those ugly if-trees where you have a number of disparate c=
ombinations requiring the same action. Today this either requires code repi=
tition or factoring into a function (which often needs to have surprisingly=
many parameters)).</div><div> </div><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><br></div><div>> Inside a case yo=
u can write continue <case label>; or continue default; to "fall" to =
another case. A plain continue; still continues the closest surrounding loo=
p for backwards compatiblity (or maybe not? -- this is a new switch stateme=
nt after all).</div><div><br></div><div>I think I'll be proposing "goto cas=
e <expr>" and "goto default", same as C# for reasons above. If =
nothing else than the existing practice should be convincing. C# is i=
n the top 5 most used languages today.</div></div></div></blockquote><div>T=
hat's a slightly more convincing argument. But not fully as C# doesn't have=
the wild gotos of C++, so goto does not signify a warning sign as it does =
in C++.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div><br></div><div>A plain "continue;" means the same in an explicit-=
specified switch as it does in a non-explicit-specified switch. The p=
roposal has a design rule which is that adding or removing the explicit spe=
cifier to a switch statement can have no effect other than making the state=
ment ill-formed or well-formed. It never changes the semantic meaning=
.. For "continue;" to mean something different would violate that. </d=
iv></div></div></blockquote><div>See my reasoning about prioritites above.&=
nbsp;</div><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> </div><div><br></div><div>> It would even be thinkable to =
let just continue; in a safe switch mean "continue with the next case" as t=
his implements the basic intention of the "safe switch": to make fall throu=
gh an explicitly called for possibility rather than the default behaviour. =
I would even be satisfied if this was the only new possibility for a "safe =
switch": Instead of using break to get out after a case you use continue no=
t to!</div><div><br></div><div>It's too late for that. Everyone termi=
nates cases with break, and uses continue to repeat an enclosing iteration =
statement. The proposal doesn't change that, it just makes implicit f=
allthrough ill-formed in an explicit-specified switch (and a couple of othe=
r little tweaks). For 97% of uses everything else is the same, the on=
ly difference is that your implicit fallthrough bugs will be caught and you=
don't have to surround case blocks in a compound statement to declare a lo=
cal variable in the case block.</div><div><br></div></div></div></blockquot=
e><div>ok, so you forbid variables from leaking into succeeding cases. I be=
t that there are people finding ways to use that misfeature of the old swit=
ch, especially those that create loops by using goto. How about the cleanup=
actions needed when these variables are no longer in scope? Won't they be =
a mandatory and error prone procedure when retrofitting 'explicit' to switc=
hes? Maybe all compilers warn about this even for simple data types (I know=
they do for variables with ctors). But warnings do get ignored or pragma-r=
emoved...</div><div><br></div><div>Question remains: How many large code ba=
ses will see 'explciit' retrofitting in reality? Is this important enough t=
o make the new switch less than optimal for new code?</div><div><br></div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div></div><div><br></div><div>On Tuesday, January 14, 2014 10:45:28 =
PM UTC+1, Bengt Gustafsson wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><div>When it comes to the goto switch and goto <expressio=
n> forms I just wanted to say that we don't need them as they promote no=
n-structured programming styles for which we already have one construct too=
many: goto. And that goto can easily be used for these cases (in the latte=
r form using a temporary variable to be able to insert a new expression int=
o the switch) if you really insist on implementing a loop with a switch but=
no looping statement.</div><div><br></div>I like the idea of a break <l=
abel>; and continue <label>; better than my own break break idea. =
I don't like the break for/while/switch/do; idea as it doesn't solve the pr=
oblem of exiting two nested for loops, which is probably the most common ca=
se. Also it is as brittle as break break; (if you change loop type and ther=
e is another one further out). I didn't know of this rather elegant Java so=
lution.<div><br></div><div>Regarding the original safe switch I suggest usi=
ng the continue keyword instead of goto as you don't have to qualify with a=
"case" keyword to disambiguate, and as the goto keyword remains as the war=
ning beacon for ugly coding it is today.</div><div><br></div><div>Thus:</di=
v><div><br></div><div>- A case in an explicit switch statement normally exi=
ts the switch statement when finished.</div><div>- Inside a case you can wr=
ite continue <case label>; or continue default; to "fall" to another =
case. A plain continue; still continues the closest surrounding loop for ba=
ckwards compatiblity (or maybe not? -- this is a new switch statement after=
all).</div><div><br></div><div>I suggest that such continues can only cont=
inue forwards, to succeding cases. This would prevent loops from forming wh=
ile allowing all combinations of cases (I think) that run in succession onc=
e. The compiler can easily check this.</div><div><br><div>You may argue tha=
t continue "normally" continues by going backwards to the start of a loop. =
I would counter that in the normal English meaning it is more logical to co=
ntinue forwards, and that it is also logical that switch statements continu=
e forwards while loops continue by going back.</div><div><br></div><div>It =
would even be thinkable to let just continue; in a safe switch mean "contin=
ue with the next case" as this implements the basic intention of the "safe =
switch": to make fall through an explicitly called for possibility rather t=
han the default behaviour. I would even be satisfied if this was the only n=
ew possibility for a "safe switch": Instead of using break to get out after=
a case you use continue not to!</div><div><br></div><div>Sorry if this cam=
e out in a confusing way, but I don't have time for more editing right now.=
</div><div><br>Den tisdagen den 14:e januari 2014 kl. 17:51:31 UTC+1 skrev =
Matthew Woehlke:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-01-14 01:15=
, Andrew Tomazos wrote:
<br>> As a second orthogonal move thereafter we could then add jump targ=
ets to
<br>> both goto and break simulatenously as follows:
<br>>
<br>> jump-target:
<br>> identifier
<br>> case expr
<br>> default
<br>> if
<br>> while
<br>> switch
<br>> do
<br>> for
<br>>
<br>> jump-statement:
<br>> goto jump-target_opt ;
<br>> break jump-target_opt;
<br>> continue ;
<br>> return expression_opt ;
<br>> return braced-init-list ;
<br>
<br>Shouldn't 'continue' also accept a jump-target_opt?
<br>
<br>e.g. (braces elided):
<br>
<br>A: for (a : list_a)
<br> B: for (b : list_b)
<br> if (cond)
<br> continue A; // done with B loop but not A lo=
op
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div></div></div></blockquote></div></div></div></blockqu=
ote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_450_8666043.1389809812051--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Wed, 15 Jan 2014 14:33:59 -0500
Raw View
--089e013c683afbf81e04f00763b6
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Jan 15, 2014 at 1:16 PM, Bengt Gustafsson <
bengt.gustafsson@beamways.com> wrote:
>
>
> Question remains: How many large code bases will see 'explciit'
> retrofitting in reality? Is this important enough to make the new switch
> less than optimal for new code?
>
>
>
I think retrofitting should be done with [[attributes]] and
warnings/errors, if existing warnings aren't enough. Even call it
[[explicit]] if you want.
I would prefer that a new language feature maximize its benefit to *new*
code. Minimize *breakage* of old code, but don't "enhance" old code.
ie I'd like the 'break' statement to be implicit (even though the keyword
is 'explicit'. At least the fallthrough would be explicit).
I also somewhat like the idea of making it single-statement (ie requiring
brackets typically). To match if/while/etc it should maybe be:
case (17) statement;
case (18) { statement; statement; }
but that leads to (for better or worse)
case (expr) statement; // ???
Also, I'm not a fan of reusing goto either. I'd rather have something that
just says does fallthrough, not jump around. Although I also agree that
the C# argument is worthwhile.
Suggestions for spelling of fallthrough:
case:
case...
....
although the last one is probably too subtle.
Or just ban fallthrough (beyond some form of the common case 1: case 2:
case 3: statement;). Leave that for old-style cases. And old-style goto.
Hmmm. I could really go with just banning fallthrough on new-style
switches.
Tony
--
---
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/.
--089e013c683afbf81e04f00763b6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jan 15, 2014 at 1:16 PM, Bengt Gustafsson <span dir=3D"ltr"=
><<a href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">ben=
gt.gustafsson@beamways.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"><br><div><br></div><div>Que=
stion remains: How many large code bases will see 'explciit' retrof=
itting in reality? Is this important enough to make the new switch less tha=
n optimal for new code?</div>
<div><div class=3D"h5"><div><br></div><br></div></div></div></blockquote></=
div><br></div><div class=3D"gmail_extra">I think retrofitting should be don=
e with [[attributes]] and warnings/errors, if existing warnings aren't =
enough.=A0 Even call it [[explicit]] if you want.<br>
<br></div><div class=3D"gmail_extra">I would prefer that a new language fea=
ture maximize its benefit to *new* code.=A0 Minimize *breakage* of old code=
, but don't "enhance" old code.<br></div><div class=3D"gmail_=
extra">
ie I'd like the 'break' statement to be implicit (even though t=
he keyword is 'explicit'.=A0 At least the fallthrough would be expl=
icit).<br><br></div><div class=3D"gmail_extra">I also somewhat like the ide=
a of making it single-statement (ie requiring brackets typically).=A0 To ma=
tch if/while/etc it should maybe be:<br>
<br>=A0=A0 case (17) statement;<br>=A0=A0 case (18) { statement; statement;=
}<br><br></div><div class=3D"gmail_extra">but that leads to (for better or=
worse)<br><br></div><div class=3D"gmail_extra">=A0=A0 case (expr) statemen=
t;=A0 // ???<br>
<br></div><div class=3D"gmail_extra"><br>Also, I'm not a fan of reusing=
goto either.=A0 I'd rather have something that just says does fallthro=
ugh, not jump around.=A0 Although I also agree that the C# argument is wort=
hwhile.<br>
<br>Suggestions for spelling of fallthrough:<br><br></div><div class=3D"gma=
il_extra">case:<br>case...<br></div><div class=3D"gmail_extra">...<br><br>a=
lthough the last one is probably too subtle.<br><br></div><div class=3D"gma=
il_extra">
Or just ban fallthrough (beyond some form of the common case 1: case 2: cas=
e 3: statement;).=A0 Leave that for old-style cases. And old-style goto.<br=
></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Hmmm=
..=A0 I could really go with just banning fallthrough on new-style switches.=
<br>
<br>Tony<br><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e013c683afbf81e04f00763b6--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 15 Jan 2014 20:34:40 -0800 (PST)
Raw View
------=_Part_5306_7721732.1389846880523
Content-Type: text/plain; charset=UTF-8
On Wednesday, January 15, 2014 7:16:52 PM UTC+1, Bengt Gustafsson wrote:
>
> By this I want to say that maybe staying as close to the original switch
> as possible may not be the best way to go. Now that I read my own sentence
> above it actually seems most logical to unify with the other control
> statements: Allow only one statement per case, if you want more use a block
> statement.
>
>>
Yes, as per the original proposal each case block in an explicit-specified
switch has its own scope, so it is just like each one is a single compound
statement. The effect of this is just so you don't need to wrap each case
block in braces to use a declaration statement within, to avoid the jump
past initialization error. Technically jump-past-initialization isn't
ill-formed, but in practice it is diagnosed anyway, so for the purposes of
the design principle about the explicit-specifier not making semantic
changes (other than making the switch ill-formed or well-formed), we
consider jump-past-initialization ill-formed in practice.
I think I'll be proposing "goto case <expr>" and "goto default", same as C#
>> for reasons above. If nothing else than the existing practice should be
>> convincing. C# is in the top 5 most used languages today.
>>
> That's a slightly more convincing argument. But not fully as C# doesn't
> have the wild gotos of C++, so goto does not signify a warning sign as it
> does in C++.
>
What do you mean C# doesn't have the "wild" gotos of C++? The (non-case)
goto statement in C# is exactly the same as the one in C++. For example,
here is your dreaded "goto loop" in C#:
using System;
class Program
{
static void Main(string[] args)
{
string name;
label: //creating label with colon(:)
Console.WriteLine("Enter your name:");
name = Console.ReadLine();
Console.WriteLine("Welcome {0}", name);
goto label; //jump to label statement
}
}
> > It would even be thinkable to let just continue; in a safe switch mean
>> "continue with the next case" as this implements the basic intention of the
>> "safe switch": to make fall through an explicitly called for possibility
>> rather than the default behaviour. I would even be satisfied if this was
>> the only new possibility for a "safe switch": Instead of using break to get
>> out after a case you use continue not to!
>>
>> It's too late for that. Everyone terminates cases with break, and uses
>> continue to repeat an enclosing iteration statement. The proposal doesn't
>> change that, it just makes implicit fallthrough ill-formed in an
>> explicit-specified switch (and a couple of other little tweaks). For 97%
>> of uses everything else is the same, the only difference is that your
>> implicit fallthrough bugs will be caught and you don't have to surround
>> case blocks in a compound statement to declare a local variable in the case
>> block.
>>
>> ok, so you forbid variables from leaking into succeeding cases. I bet
> that there are people finding ways to use that misfeature of the old
> switch, especially those that create loops by using goto. How about the
> cleanup actions needed when these variables are no longer in scope? Won't
> they be a mandatory and error prone procedure when retrofitting 'explicit'
> to switches? Maybe all compilers warn about this even for simple data types
> (I know they do for variables with ctors). But warnings do get ignored or
> pragma-removed...
>
> Question remains: How many large code bases will see 'explciit'
> retrofitting in reality? Is this important enough to make the new switch
> less than optimal for new code?
>
Noone is advocating going back and modifying existing code to add the
explicit-specifier to switch statements. The semantics of existing and
future non-explicit-specified switches are completely unchanged by the
proposal. The intention is that (if you want) you can start adding the
explicit-specifier to switch statements you write in new code. For those
that don't want to use, or haven't heard about explicit-specified switches,
they can keep using non-explicit-specified switches. Likewise those that
don't want to use, or haven't heard about the goto case statement, can just
not use it. The proposal just gives the programmer some additional
options. If you explicit-specify a switch, it gives each case block its
own scope and makes flowing off the end of it ill-formed. If you write
"goto case expr", it jumps to that case. Both semantics are all
well-tested by C#. It really is pretty straight-forward stuff.
--
---
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_5306_7721732.1389846880523
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, January 15, 2014 7:16:52 PM UTC+1, Bengt Gus=
tafsson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>By this I want to say that maybe staying as close to the original swi=
tch as possible may not be the best way to go. Now that I read my own sente=
nce above it actually seems most logical to unify with the other control st=
atements: Allow only one statement per case, if you want more use a block s=
tatement.</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div></div></div></div></blockquote></div></blockquote><div><br></div><di=
v>Yes, as per the original proposal each case block in an explicit-specifie=
d switch has its own scope, so it is just like each one is a single compoun=
d statement. The effect of this is just so you don't need to wrap eac=
h case block in braces to use a declaration statement within, to avoid the =
jump past initialization error. Technically jump-past-initialization =
isn't ill-formed, but in practice it is diagnosed anyway, so for the purpos=
es of the design principle about the explicit-specifier not making semantic=
changes (other than making the switch ill-formed or well-formed), we consi=
der jump-past-initialization ill-formed in practice.</div><div><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote cla=
ss=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>I think I'll be proposi=
ng "goto case <expr>" and "goto default", same as C# for reasons abov=
e. If nothing else than the existing practice should be convincing. &=
nbsp;C# is in the top 5 most used languages today.</div></div></div></block=
quote><div>That's a slightly more convincing argument. But not fully as C# =
doesn't have the wild gotos of C++, so goto does not signify a warning sign=
as it does in C++.</div></div></blockquote><div><br></div><div>What do you=
mean C# doesn't have the "wild" gotos of C++? The (non-case) goto st=
atement in C# is exactly the same as the one in C++. For example, her=
e is your dreaded "goto loop" in C#:</div><div><br></div><div><span data-ic=
eapw=3D"1" style=3D"letter-spacing: 1px; text-align: justify; font-size: 9p=
t; font-family: 'Courier New'; color: blue;"> using</span><span data-=
iceapw=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align:=
justify; font-size: 9pt; font-family: 'Courier New';"> System;</span>=
<br style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Lucida Grande', Verd=
ana, Helvetica, sans-serif; letter-spacing: 1px; line-height: 20.7999992370=
60547px; text-align: justify;"><span class=3D"Apple-style-span" style=3D"co=
lor: rgb(0, 0, 0); letter-spacing: 1px; font-family: 'Courier New'; font-si=
ze: 12px;"> </span><br style=3D"color: rgb(0, 0, 0); font-family: Aria=
l, 'Lucida Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px; li=
ne-height: 20.799999237060547px; text-align: justify;"><span class=3D"Apple=
-style-span" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing=
: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;">&=
nbsp; </span><span class=3D"Apple-style-span" data-iceapw=3D"1" data-i=
ceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: =
justify; font-family: 'Courier New'; font-size: 12px;"><span data-iceapw=3D=
"1" style=3D"color: blue;">class</span></span><span class=3D"Apple-style-sp=
an" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify;=
font-family: 'Courier New'; font-size: 12px;"> </span><span class=3D"=
Apple-style-span" data-iceapw=3D"1" data-iceapc=3D"1" style=3D"color: rgb(0=
, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courier Ne=
w'; font-size: 12px;"><span data-iceapw=3D"1" style=3D"color: rgb(43, 145, =
175);">Program</span></span><br style=3D"color: rgb(0, 0, 0); font-family: =
Arial, 'Lucida Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px=
; line-height: 20.799999237060547px; text-align: justify;"><span class=3D"A=
pple-style-span" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spa=
cing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px=
;"> </span><span class=3D"Apple-style-span" data-iceapw=3D=
"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify;=
font-family: 'Courier New'; font-size: 12px;">{</span><br style=3D"color: =
rgb(0, 0, 0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans=
-serif; letter-spacing: 1px; line-height: 20.799999237060547px; text-align:=
justify;"><span class=3D"Apple-style-span" data-iceapc=3D"1" style=3D"colo=
r: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Co=
urier New'; font-size: 12px;"> </span><span class=
=3D"Apple-style-span" data-iceapw=3D"1" data-iceapc=3D"1" style=3D"color: r=
gb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courie=
r New'; font-size: 12px;"><span data-iceapw=3D"1" style=3D"color: blue;">st=
atic</span></span><span class=3D"Apple-style-span" style=3D"color: rgb(0, 0=
, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courier New';=
font-size: 12px;"> </span><span class=3D"Apple-style-span" data-iceap=
w=3D"1" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px=
; text-align: justify; font-family: 'Courier New'; font-size: 12px;"><span =
data-iceapw=3D"1" style=3D"color: blue;">void</span></span><span class=3D"A=
pple-style-span" data-iceapw=3D"1" style=3D"color: rgb(0, 0, 0); letter-spa=
cing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px=
;"> Main(</span><span class=3D"Apple-style-span" data-iceapw=3D"1" dat=
a-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-alig=
n: justify; font-family: 'Courier New'; font-size: 12px;"><span data-iceapw=
=3D"1" style=3D"color: blue;">string</span></span><span class=3D"Apple-styl=
e-span" data-iceapw=3D"2" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px=
; text-align: justify; font-family: 'Courier New'; font-size: 12px;">[] arg=
s)</span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Lucida Gran=
de', Verdana, Helvetica, sans-serif; letter-spacing: 1px; line-height: 20.7=
99999237060547px; text-align: justify;"><span class=3D"Apple-style-span" da=
ta-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-ali=
gn: justify; font-family: 'Courier New'; font-size: 12px;"> &nb=
sp; </span><span class=3D"Apple-style-span" data-iceapw=3D"1" style=
=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-fam=
ily: 'Courier New'; font-size: 12px;">{</span><br style=3D"color: rgb(0, 0,=
0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans-serif; l=
etter-spacing: 1px; line-height: 20.799999237060547px; text-align: justify;=
"><span class=3D"Apple-style-span" data-iceapc=3D"1" style=3D"color: rgb(0,=
0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courier New=
'; font-size: 12px;"> </span><span class=3D=
"Apple-style-span" data-iceapw=3D"1" data-iceapc=3D"1" style=3D"color: rgb(=
0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courier N=
ew'; font-size: 12px;"><span data-iceapw=3D"1" style=3D"color: blue;">strin=
g</span></span><span class=3D"Apple-style-span" data-iceapw=3D"1" style=3D"=
color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family:=
'Courier New'; font-size: 12px;"> name;</span><br style=3D"color: rgb=
(0, 0, 0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans-se=
rif; letter-spacing: 1px; line-height: 20.799999237060547px; text-align: ju=
stify;"><span class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 0); lett=
er-spacing: 1px; text-align: justify; font-family: 'Courier New'; font-size=
: 12px;"> </span><br style=3D"color: rgb(0, 0, 0); font-family: Arial,=
'Lucida Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px; line=
-height: 20.799999237060547px; text-align: justify;"><span class=3D"Apple-s=
tyle-span" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: =
1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;">&nb=
sp; </span><span class=3D"Apple-style-span" data-=
iceapw=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align:=
justify; font-family: 'Courier New'; font-size: 12px;">label: </span>=
<span class=3D"Apple-style-span" data-iceapw=3D"4" data-iceapc=3D"1" style=
=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-fam=
ily: 'Courier New'; font-size: 12px;"><span data-iceapw=3D"4" style=3D"colo=
r: green;">//creating label with colon(:)</span></span><br style=3D"color: =
rgb(0, 0, 0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans=
-serif; letter-spacing: 1px; line-height: 20.799999237060547px; text-align:=
justify;"><span class=3D"Apple-style-span" style=3D"letter-spacing: 1px; t=
ext-align: justify; color: rgb(0, 128, 0); font-family: 'Courier New'; font=
-size: 12px;"> </span><br style=3D"color: rgb(0, 0, 0); font-family: A=
rial, 'Lucida Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px;=
line-height: 20.799999237060547px; text-align: justify;"><span class=3D"Ap=
ple-style-span" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spac=
ing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;=
"> </span><span class=3D"Apple-style-span" =
data-iceapw=3D"1" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-sp=
acing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12p=
x;"><span data-iceapw=3D"1" style=3D"color: rgb(43, 145, 175);">Console</sp=
an></span><span class=3D"Apple-style-span" data-iceapw=3D"1" style=3D"color=
: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Cou=
rier New'; font-size: 12px;">.WriteLine(</span><span class=3D"Apple-style-s=
pan" data-iceapw=3D"4" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); lett=
er-spacing: 1px; text-align: justify; font-family: 'Courier New'; font-size=
: 12px;"><span data-iceapw=3D"4" style=3D"color: rgb(163, 21, 21);">"Enter&=
nbsp;your name:"</span></span><span class=3D"Apple-style-span" data-iceapw=
=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justi=
fy; font-family: 'Courier New'; font-size: 12px;">);</span><br style=3D"col=
or: rgb(0, 0, 0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, =
sans-serif; letter-spacing: 1px; line-height: 20.799999237060547px; text-al=
ign: justify;"><span class=3D"Apple-style-span" data-iceapc=3D"1" style=3D"=
color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family:=
'Courier New'; font-size: 12px;"> </span><=
span class=3D"Apple-style-span" data-iceapw=3D"2" style=3D"color: rgb(0, 0,=
0); letter-spacing: 1px; text-align: justify; font-family: 'Courier New'; =
font-size: 12px;">name =3D </span><span class=3D"Apple-style-span" dat=
a-iceapw=3D"1" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spaci=
ng: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;"=
><span data-iceapw=3D"1" style=3D"color: rgb(43, 145, 175);">Console</span>=
</span><span class=3D"Apple-style-span" data-iceapw=3D"1" style=3D"color: r=
gb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Courie=
r New'; font-size: 12px;">.ReadLine();</span><br style=3D"color: rgb(0, 0, =
0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans-serif; le=
tter-spacing: 1px; line-height: 20.799999237060547px; text-align: justify;"=
><span class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 0); letter-spac=
ing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;=
"> </span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Lucid=
a Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px; line-height=
: 20.799999237060547px; text-align: justify;"><span class=3D"Apple-style-sp=
an" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; te=
xt-align: justify; font-family: 'Courier New'; font-size: 12px;"> &nbs=
p; </span><span class=3D"Apple-style-span" data-iceapw=
=3D"1" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px;=
text-align: justify; font-family: 'Courier New'; font-size: 12px;"><span d=
ata-iceapw=3D"1" style=3D"color: rgb(43, 145, 175);">Console</span></span><=
span class=3D"Apple-style-span" data-iceapw=3D"1" style=3D"color: rgb(0, 0,=
0); letter-spacing: 1px; text-align: justify; font-family: 'Courier New'; =
font-size: 12px;">.WriteLine(</span><span class=3D"Apple-style-span" data-i=
ceapw=3D"2" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing:=
1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;"><s=
pan data-iceapw=3D"2" style=3D"color: rgb(163, 21, 21);">"Welcome {0}"</spa=
n></span><span class=3D"Apple-style-span" data-iceapw=3D"2" style=3D"color:=
rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: 'Cour=
ier New'; font-size: 12px;">, name);</span><br style=3D"color: rgb(0, 0, 0)=
; font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans-serif; lett=
er-spacing: 1px; line-height: 20.799999237060547px; text-align: justify;"><=
span class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 0); letter-spacin=
g: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;">=
</span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Lucida =
Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px; line-height: =
20.799999237060547px; text-align: justify;"><span class=3D"Apple-style-span=
" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text=
-align: justify; font-family: 'Courier New'; font-size: 12px;"> =
</span><span class=3D"Apple-style-span" data-iceapw=3D=
"1" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; te=
xt-align: justify; font-family: 'Courier New'; font-size: 12px;"><span data=
-iceapw=3D"1" style=3D"color: blue;">goto</span></span><span class=3D"Apple=
-style-span" data-iceapw=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing=
: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12px;">&=
nbsp;label; </span><span class=3D"Apple-style-span" data-iceapw=3D"4" =
data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-a=
lign: justify; font-family: 'Courier New'; font-size: 12px;"><span data-ice=
apw=3D"4" style=3D"color: green;">//jump to label statement</span></sp=
an><span class=3D"Apple-style-span" style=3D"color: rgb(0, 0, 0); letter-sp=
acing: 1px; text-align: justify; font-family: 'Courier New'; font-size: 12p=
x;"> </span><br style=3D"color=
: rgb(0, 0, 0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sa=
ns-serif; letter-spacing: 1px; line-height: 20.799999237060547px; text-alig=
n: justify;"><span class=3D"Apple-style-span" data-iceapc=3D"1" style=3D"co=
lor: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-family: '=
Courier New'; font-size: 12px;"> </span><span clas=
s=3D"Apple-style-span" data-iceapw=3D"1" style=3D"color: rgb(0, 0, 0); lett=
er-spacing: 1px; text-align: justify; font-family: 'Courier New'; font-size=
: 12px;">}</span><br style=3D"color: rgb(0, 0, 0); font-family: Arial, 'Luc=
ida Grande', Verdana, Helvetica, sans-serif; letter-spacing: 1px; line-heig=
ht: 20.799999237060547px; text-align: justify;"><span class=3D"Apple-style-=
span" data-iceapc=3D"1" style=3D"color: rgb(0, 0, 0); letter-spacing: 1px; =
text-align: justify; font-family: 'Courier New'; font-size: 12px;"> &n=
bsp; </span><span class=3D"Apple-style-span" data-iceapw=3D"1" style=
=3D"color: rgb(0, 0, 0); letter-spacing: 1px; text-align: justify; font-fam=
ily: 'Courier New'; font-size: 12px;">}</span><br style=3D"color: rgb(0, 0,=
0); font-family: Arial, 'Lucida Grande', Verdana, Helvetica, sans-serif; l=
etter-spacing: 1px; line-height: 20.799999237060547px; text-align: justify;=
"></div><div> </div><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"><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>> It would even be thinkable to let just continue; in a safe switch =
mean "continue with the next case" as this implements the basic intention o=
f the "safe switch": to make fall through an explicitly called for possibil=
ity rather than the default behaviour. I would even be satisfied if this wa=
s the only new possibility for a "safe switch": Instead of using break to g=
et out after a case you use continue not to!</div><div><br></div><div>It's =
too late for that. Everyone terminates cases with break, and uses con=
tinue to repeat an enclosing iteration statement. The proposal doesn'=
t change that, it just makes implicit fallthrough ill-formed in an explicit=
-specified switch (and a couple of other little tweaks). For 97% of u=
ses everything else is the same, the only difference is that your implicit =
fallthrough bugs will be caught and you don't have to surround case blocks =
in a compound statement to declare a local variable in the case block.</div=
><div><br></div></div></div></blockquote><div>ok, so you forbid variables f=
rom leaking into succeeding cases. I bet that there are people finding ways=
to use that misfeature of the old switch, especially those that create loo=
ps by using goto. How about the cleanup actions needed when these variables=
are no longer in scope? Won't they be a mandatory and error prone procedur=
e when retrofitting 'explicit' to switches? Maybe all compilers warn about =
this even for simple data types (I know they do for variables with ctors). =
But warnings do get ignored or pragma-removed...</div><div><br></div><div>Q=
uestion remains: How many large code bases will see 'explciit' retrofitting=
in reality? Is this important enough to make the new switch less than opti=
mal for new code?</div></div></blockquote><div><br></div><div>Noone is advo=
cating going back and modifying existing code to add the explicit-specifier=
to switch statements. The semantics of existing and future non-expli=
cit-specified switches are completely unchanged by the proposal. The =
intention is that (if you want) you can start adding the explicit-specifier=
to switch statements you write in new code. For those that don't wan=
t to use, or haven't heard about explicit-specified switches, they can keep=
using non-explicit-specified switches. Likewise those that don't wan=
t to use, or haven't heard about the goto case statement, can just not use =
it. The proposal just gives the programmer some additional options. &=
nbsp;If you explicit-specify a switch, it gives each case block its own sco=
pe and makes flowing off the end of it ill-formed. If you write "goto=
case expr", it jumps to that case. Both semantics are all well-teste=
d by C#. It really is pretty straight-forward stuff.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5306_7721732.1389846880523--
.
Author: masse.nicolas@gmail.com
Date: Fri, 7 Feb 2014 04:49:47 -0800 (PST)
Raw View
------=_Part_188_3532337.1391777387549
Content-Type: text/plain; charset=UTF-8
Some though about your proposal:
- I'm a bit perturbed by the idea of adding a new switch statement. I find
it quite unclear for newcomers. Also It could be difficult to know when we
are in the middle of some code if we are inside a switch or insde an
explicit switch statement. (Typically, we'll have to scroll to the
enclosing switch statement to know that).
- the"goto case *label"* seems to be a nice solution to me. I makes thing
clear on what the code does, and also could avoid errors when reorganizing
the order of the labels inside a switch statement. Personnally, I'm in
favor of this solution instead of the addition of a [[fall]] attribute for
example.
- AFAIK, the addition of the "goto case *label" *could be made in the
existing switch statement. It does not require a new explicit switch
statement and won't break existing code.
- For existing code, the compilers could be made so that they will emit a
warning if there is an implicit fallthrouh in the code. Going further, we
could imagine that some of them will add a flag to make implicit fallthrouh
resulting in an error instead of a warning. Anyway, that's outside the
scope of the standard. The only things here is that implicit fallthrouh
should still compile by default.
- for local variables declarations, the current statement could be changed
so that each variable declaration inside a case statement (or the default
statement) is local to the case/default statment instead of being local to
the whole switch statement. Note that such a changes could potentially
break existing code if a variable is declared inside a case and used inside
another case. (Having an idea on how much code will be affected by such a
changes could be interesting).
- I the above solution can't be done because it will break too much code,
then the solution of adding extra braces could be keept. In the end, that's
not something really problematic once you know how it works.
--
---
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_188_3532337.1391777387549
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Some though about your proposal:<br><br>- I'm a bit pertur=
bed by the idea of adding a new switch statement. I find it quite unclear f=
or newcomers. Also It could be difficult to know when we are in the middle =
of some code if we are inside a switch or insde an explicit switch statemen=
t. (Typically, we'll have to scroll to the enclosing switch statement to kn=
ow that).<br>- the"goto case <i>label"</i> seems to be a nice solution to m=
e. I makes thing clear on what the code does, and also could avoid errors w=
hen reorganizing the order of the labels inside a switch statement. Personn=
ally, I'm in favor of this solution instead of the addition of a [[fall]] a=
ttribute for example.<br>- AFAIK, the addition of the "goto case <i>label" =
</i>could<i> </i>be made in the existing switch statement. It does not requ=
ire a new explicit switch statement and won't break existing code. <br>- Fo=
r existing code, the compilers could be made so that they will emit a warni=
ng if there is an implicit fallthrouh in the code. Going further, we could =
imagine that some of them will add a flag to make implicit fallthrouh resu=
lting in an error instead of a warning. Anyway, that's outside the scope of=
the standard. The only things here is that implicit fallthrouh should stil=
l compile by default.<br>- for local variables declarations, the current st=
atement could be changed so that each variable declaration inside a case st=
atement (or the default statement) is local to the case/default statment in=
stead of being local to the whole switch statement. Note that such a change=
s could potentially break existing code if a variable is declared inside a =
case and used inside another case. (Having an idea on how much code will be=
affected by such a changes could be interesting).<br>- I the above solutio=
n can't be done because it will break too much code, then the solution of a=
dding extra braces could be keept. In the end, that's not something really =
problematic once you know how it works.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_188_3532337.1391777387549--
.