Topic: Java-style labeled break/continue, standalone
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 1 Aug 2014 10:50:51 -0700 (PDT)
Raw View
------=_Part_170_1114617129.1406915451620
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think C++ (and C, for that matter) should add Java-style labeled break=20
and continue to the language. It would eliminate one of the bigger uses of=
=20
goto, is simple to understand, and has no backward-compatibility concerns=
=20
(because this syntax is always ill-formed now).
Java's labeled break and continue allow you to put labels on for/do/while/
switch and use statements like "break label;" to break out of loops that=20
are not the innermost to your current statement. This is sometimes useful=
=20
for things like iterating multi-level arrays and dealing with switch=20
statements inside of loops.
The change ends up making break, continue and goto be three loop operations=
=20
with the same syntax(*) but different effects. break means terminate the=
=20
target loop. continue means immediately go to the next iteration of the=20
target loop. goto means restart the target loop. It's kind of like=20
closing the set of operations, I suppose. (* goto with no parameters being=
=20
defined as restarting the current loop would be really weird! There's no=
=20
real reason to do that, because a labeled for (;;) with continue and a brea=
k=20
does the same thing.)
This has been discussed before, but it got grouped with other changes that=
=20
were much more controversial. This change can be on its own much more=20
simply. I made a change list below in what I hope is a simple format to=20
understand. I hope I did it right...and I hope that others think that this=
=20
is a good idea.
Melissa
*6.6 Jump statements [stmt.jump]*
(1) Jump statements unconditionally transfer control.
=20
*jump-statement:* break *identifieropt* ;
continue *identifieropt* ;
return *expressionopt* ;
return *braced-init-list* ;
goto *identifier* ;
....
*6.6.1 The break statement [stmt.break]*
(1) The break statement shall occur only in an *iteration-statement* or a=
=20
switch statement and causes termination of the *iteration-statement* or=20
switch statement labeled by *identifieropt*, or, if *identifieropt* is=20
omitted, causes termination of the smallest enclosing *iteration-statement*=
=20
or switch statement; control passes to the statement following the=20
terminated statement, if any. If *identifieropt* labels a statement other=
=20
than an *iteration-statement* or a switch statement enclosing the break=20
statement, the program is ill-formed. [=20
*Example:*enum class command {
hello,
quit,
};
command get_command();
void initialize();
void deinitialize();
int main() {
initialize();
main_loop: for (;;) {
switch (get_command()) {
case command::hello:
std::cout << "hello" << endl;
break; // exits switch statement
case command::quit:
std::cout << "goodbye" << endl;
break main_loop; // exits for statement and proceeds at=20
deinitialize() call
}
}
deinitialize();
return 0;
}
*=E2=80=94 end example* ]
*6.2.2 The continue statement [stmt.cont]*
(1) The continue statement shall occur only in an *iteration-statement*=20
and causes control to pass to the loop-continuation portion (that is, to=20
the end of the loop) of the *iteration-statement* labeled by identifieropt,=
=20
or, if identifieropt is omitted, the smallest enclosing=20
*iteration-statement* , that is, to the end of the loop. (If=20
*identifieropt* labels a statement other than an *iteration-statement*=20
enclosing the continue statement, the program is ill-formed.) More=20
precisely, within each of the statements
loop: while (foo) {
{
// ...
}
contin: ;
}
loop: do {
{
// ...
}
contin: ;
} while (foo);
loop: for (;;) {
{
// ...
}
contin: ;
}
continue loop, or a continue omitting *identifieropt* not contained in an a=
=20
deeper-enclosed iteration statement, is equivalent to goto contin.
(The comma added above between "statement" and "is" is important. It=20
doesn't matter whether continue loop is in a deeper-enclosed iteration=20
statement.)
Note for my changes: 6.1 [stmt.label] doesn't need to change, even though=
=20
it mentions goto, because Java-style break and continue can't reference=20
labels before they're defined.
--=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_170_1114617129.1406915451620
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think C++ (and C, for that matter) should add Java-style=
labeled <span style=3D"font-family: courier new,monospace;">break</span> a=
nd <span style=3D"font-family: courier new,monospace;">continue</span> to t=
he language. It would eliminate one of the bigger uses of <span style=
=3D"font-family: courier new,monospace;">goto</span>, is simple to understa=
nd, and has no backward-compatibility concerns (because this syntax is alwa=
ys ill-formed now).<br><br>Java's labeled break and continue allow you to p=
ut labels on <span style=3D"font-family: courier new,monospace;">for</span>=
/<span style=3D"font-family: courier new,monospace;">do</span>/<span style=
=3D"font-family: courier new,monospace;">while</span>/<span style=3D"font-f=
amily: courier new,monospace;">switch</span> and use statements like "<span=
style=3D"font-family: courier new,monospace;">break label;</span>" to brea=
k out of loops that are not the innermost to your current statement. =
This is sometimes useful for things like iterating multi-level arrays and d=
ealing with <span style=3D"font-family: courier new,monospace;">switch</spa=
n> statements inside of loops.<br><br>The change ends up making <span style=
=3D"font-family: courier new,monospace;">break</span>, <span style=3D"font-=
family: courier new,monospace;">continue</span> and <span style=3D"font-fam=
ily: courier new,monospace;">goto</span> be three loop operations with the =
same syntax(*) but different effects. <span style=3D"font-family: cou=
rier new,monospace;">break</span> means terminate the target loop. <s=
pan style=3D"font-family: courier new,monospace;">continue</span> means imm=
ediately go to the next iteration of the target loop. <span style=3D"=
font-family: courier new,monospace;">goto</span> means restart the target l=
oop. It's kind of like closing the set of operations, I suppose. =
; (* <span style=3D"font-family: courier new,monospace;">goto</span> with n=
o parameters being defined as restarting the current loop would be really w=
eird! There's no real reason to do that, because a labeled <span styl=
e=3D"font-family: courier new,monospace;">for (;;)</span> with <span style=
=3D"font-family: courier new,monospace;">continue</span> and a <span style=
=3D"font-family: courier new,monospace;">break</span> does the same thing.)=
<br><br>This has been discussed before, but it got grouped with other chang=
es that were much more controversial. This change can be on its own m=
uch more simply. I made a change list below in what I hope is a simpl=
e format to understand. I hope I did it right...and I hope that other=
s think that this is a good idea.<br><br>Melissa<br><br><br><b>6.6 Jump sta=
tements [stmt.jump]</b><br><br>(1) Jump statements unconditionally tr=
ansfer control.<br> <i>jump-statement:<br></i>  =
; <span style=3D"font-family: courier new,mon=
ospace;">break</span> <span style=3D"background-color: rgb(217, 234, 211);"=
><span style=3D"color: rgb(0, 0, 0);"><i>identifier<font size=3D"1">opt</fo=
nt></i></span></span> <span style=3D"font-family: courier new,monospace;">;=
</span><br> <span style=3D"font-f=
amily: courier new,monospace;">continue</span> <span style=3D"background-co=
lor: rgb(217, 234, 211);"><i>identifier<font size=3D"1">opt</font></i></spa=
n> <span style=3D"font-family: courier new,monospace;">;</span><br> &n=
bsp; <span style=3D"font-family: courier new,=
monospace;">return</span> <i>expression<font size=3D"1">opt</font></i> <spa=
n style=3D"font-family: courier new,monospace;">;</span><br> &nb=
sp; <span style=3D"font-family: courier new,monospa=
ce;">return</span> <i>braced-init-list</i> <span style=3D"font-family: cour=
ier new,monospace;">;</span><br> =
<span style=3D"font-family: courier new,monospace;">goto</span> <i>identifi=
er</i> <span style=3D"font-family: courier new,monospace;">;</span><br><br>=
....<br><br><b>6.6.1 The <span style=3D"font-family: courier new,monospace;"=
>break</span> statement [stmt.break]</b><br><br>(1) The <span style=
=3D"font-family: courier new,monospace;">break</span> statement shall occur=
only in an <i>iteration-statement</i> or a <span style=3D"font-family: cou=
rier new,monospace;">switch</span> statement and causes termination of the =
<span style=3D"background-color: rgb(217, 234, 211);"><i>iteration-statemen=
t</i> or <span style=3D"font-family: courier new,monospace;">switch</span> =
statement labeled by <i>identifier<font size=3D"1">opt</font></i>, or, if <=
i>identifier<font size=3D"1">opt</font></i> is omitted, causes termination =
of the</span> smallest enclosing <i>iteration-statement</i> or <span style=
=3D"font-family: courier new,monospace;">switch</span> statement; control p=
asses to the statement following the terminated statement, if any. <s=
pan style=3D"background-color: rgb(217, 234, 211);">If <i>identifier<font s=
ize=3D"1">opt</font></i> labels a statement other than an <i>iteration-stat=
ement</i> or a <span style=3D"font-family: courier new,monospace;">switch</=
span> statement enclosing the <span style=3D"font-family: courier new,monos=
pace;">break</span> statement, the program is ill-formed.</span> <spa=
n style=3D"background-color: rgb(217, 234, 211);">[ <i>Example:<br><br></i>=
<span style=3D"font-family: courier new,monospace;">enum class command {<br=
> hello,<br> quit,<br>};<br>command get_command();<br>void init=
ialize();<br>void deinitialize();<br><br>int main() {<br> initialize(=
);<br> main_loop: for (;;) {<br> switch (get_comman=
d()) {<br> case command::hello:<br> &nbs=
p; std::cout << "hello" << endl;<=
br> break; // <span style=
=3D"font-family: arial,sans-serif;">exits switch statement</span><br> =
case command::quit:<br> &nb=
sp; std::cout << "goodbye" << endl;<br> =
break main_loop; // <span style=3D"fon=
t-family: arial,sans-serif;">exits for statement and proceeds at <span styl=
e=3D"font-family: courier new,monospace;">deinitialize()</span> call</span>=
<br> }<br> }<br> deinitialize();<br> re=
turn 0;<br>}<br></span><br><i>=E2=80=94 end example</i> ]</span><br><br><b>=
6.2.2 The <span style=3D"font-family: courier new,monospace;">continue</spa=
n> statement [stmt.cont]</b><br><br>(1) The <span style=3D"font-famil=
y: courier new,monospace;">continue</span> statement shall occur only in an=
<i>iteration-statement</i> and causes control to pass to the loop-continua=
tion portion <span style=3D"background-color: rgb(217, 234, 211);">(that is=
, to the end of the loop)</span> of the <span style=3D"background-color: rg=
b(217, 234, 211);"><i>iteration-statement</i> labeled by identifieropt, or,=
if identifieropt is omitted, the</span> smallest enclosing <i>iteration-st=
atement</i> <span style=3D"background-color: rgb(244, 204, 204);">, that is=
, to the end of the loop</span>. <span style=3D"background-color: rgb=
(217, 234, 211);">(If <i>identifier<font size=3D"1">opt</font></i> labels a=
statement other than an <i>iteration-statement</i> enclosing the <span sty=
le=3D"font-family: courier new,monospace;">continue</span> statement, the p=
rogram is ill-formed.)</span> More precisely, <span style=3D"backgrou=
nd-color: rgb(217, 234, 211);">with</span>in each of the statements<br><br>=
<span style=3D"font-family: courier new,monospace;"><span style=3D"backgrou=
nd-color: rgb(217, 234, 211);">loop: </span>while (foo) {<br> {<br>&n=
bsp; // <span style=3D"font-family: arial,sans-serif;">...</spa=
n><br> }<br>contin: ;<br>}<br><br><span style=3D"background-color: rg=
b(217, 234, 211);">loop: </span>do {<br> {<br> // <=
span style=3D"font-family: arial,sans-serif;">...</span><br> }<br>con=
tin: ;<br>} while (foo);<br><br><span style=3D"background-color: rgb(217, 2=
34, 211);">loop: </span>for (;;) {<br> {<br> // <sp=
an style=3D"font-family: arial,sans-serif;">...</span><br> }<br>conti=
n: ;<br>}<br></span><br><span style=3D"font-family: courier new,monospace;"=
><span style=3D"background-color: rgb(217, 234, 211);">continue loop</span>=
</span><span style=3D"background-color: rgb(217, 234, 211);">, or</span> a =
<span style=3D"font-family: courier new,monospace;">continue</span> <span s=
tyle=3D"background-color: rgb(217, 234, 211);">omitting <i>identifier<font =
size=3D"1">opt</font></i></span> not contained in <span style=3D"background=
-color: rgb(244, 204, 204);">an</span> <span style=3D"background-color: rgb=
(217, 234, 211);">a deeper-</span>enclosed iteration statement<span style=
=3D"background-color: rgb(217, 234, 211);">,</span> is equivalent to <span =
style=3D"font-family: courier new,monospace;">goto contin</span>.<br><br><s=
pan style=3D"background-color: rgb(255, 242, 204);">(The comma added above =
between "statement" and "is" is important. It doesn't matter whether =
<span style=3D"font-family: courier new,monospace;">continue loop</span> is=
in a deeper-enclosed iteration statement.)</span><br><br><span style=3D"ba=
ckground-color: rgb(255, 242, 204);">Note for my changes: 6.1 [stmt.label] =
doesn't need to change, even though it mentions <span style=3D"font-family:=
courier new,monospace;">goto</span>, because Java-style <span style=3D"fon=
t-family: courier new,monospace;">break</span> and <span style=3D"font-fami=
ly: courier new,monospace;">continue</span> can't reference labels before t=
hey're defined.</span><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_170_1114617129.1406915451620--
.
Author: Thomas Koeppe <tkoeppe@google.com>
Date: Fri, 1 Aug 2014 11:13:44 -0700 (PDT)
Raw View
------=_Part_418_130818386.1406916824493
Content-Type: text/plain; charset=UTF-8
I believe something similar is the subject of proposal N3879
<http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf>, which was
discussed in Rapperswil. I think it did not gain a lot of support.
--
---
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_418_130818386.1406916824493
Content-Type: text/html; charset=UTF-8
<div dir="ltr">I believe something similar is the subject of <a href="http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf">proposal N3879</a>, which was discussed in Rapperswil. I think it did not gain a lot of support.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_418_130818386.1406916824493--
.
Author: Myriachan <myriachan@gmail.com>
Date: Fri, 1 Aug 2014 11:18:12 -0700 (PDT)
Raw View
------=_Part_469_1983004433.1406917093235
Content-Type: text/plain; charset=UTF-8
On Friday, August 1, 2014 11:13:44 AM UTC-7, Thomas Koeppe wrote:
>
> I believe something similar is the subject of proposal N3879
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf>, which
> was discussed in Rapperswil. I think it did not gain a lot of support.
>
Yep, thanks. This is the proposal I was referring to where it got grouped
up with more-controversial changes. Essentially, this is just splitting
off the break/continue part...
--
---
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_469_1983004433.1406917093235
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, August 1, 2014 11:13:44 AM UTC-7, Thomas Koeppe=
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">I beli=
eve something similar is the subject of <a href=3D"http://open-std.org/jtc1=
/sc22/wg21/docs/papers/2014/n3879.pdf" target=3D"_blank" onmousedown=3D"thi=
s.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2F=
sc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\46sa\75D\46sntz\0751\46usg\7=
5AFQjCNH8yqW-D-45bD8Vzl-z8XSa9iKp0w';return true;" onclick=3D"this.href=3D'=
http://www.google.com/url?q\75http%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg2=
1%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNH8y=
qW-D-45bD8Vzl-z8XSa9iKp0w';return true;">proposal N3879</a>, which was=
discussed in Rapperswil. I think it did not gain a lot of support.</div></=
blockquote><div><br>Yep, thanks. This is the proposal I was referring=
to where it got grouped up with more-controversial changes. Essentia=
lly, this is just splitting off the break/continue part... <br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_469_1983004433.1406917093235--
.
Author: Francis Smit <grizzlysmit@gmail.com>
Date: Sat, 02 Aug 2014 05:18:22 +1000
Raw View
This is a multi-part message in MIME format.
--------------020104010009040807070201
Content-Type: text/plain; charset=UTF-8; format=flowed
On 02/08/14 04:18, Myriachan wrote:
> On Friday, August 1, 2014 11:13:44 AM UTC-7, Thomas Koeppe wrote:
>
> I believe something similar is the subject of proposal N3879
> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf>,
> which was discussed in Rapperswil. I think it did not gain a lot
> of support.
>
>
> Yep, thanks. This is the proposal I was referring to where it got
> grouped up with more-controversial changes. Essentially, this is just
> splitting off the break/continue part...
>
I for one support this but I didn't support proposal N3879
<http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf>, because
of it other stuff.
--
.~. In my life God comes first....
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ http://www.smit.id.au/
--
---
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/.
--------------020104010009040807070201
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
</head>
<body bgcolor=3D"#FFFFFF" text=3D"#000000">
<div class=3D"moz-cite-prefix">On 02/08/14 04:18, Myriachan wrote:<br>
</div>
<blockquote
cite=3D"mid:dfceffb9-225d-4305-97f8-c5fe69f868ff@isocpp.org"
type=3D"cite">
<div dir=3D"ltr">On Friday, August 1, 2014 11:13:44 AM UTC-7, Thomas
Koeppe 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">I believe something similar is the subject of <a
moz-do-not-send=3D"true"
href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n=
3879.pdf"
target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75htt=
p%3A%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.=
pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNH8yqW-D-45bD8Vzl-z8XSa9iKp0w';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A=
%2F%2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\=
46sa\75D\46sntz\0751\46usg\75AFQjCNH8yqW-D-45bD8Vzl-z8XSa9iKp0w';return
true;">proposal=C2=A0N3879</a>, which was discussed in
Rapperswil. I think it did not gain a lot of support.</div>
</blockquote>
<div><br>
Yep, thanks.=C2=A0 This is the proposal I was referring to where =
it
got grouped up with more-controversial changes.=C2=A0 Essentially=
,
this is just splitting off the break/continue part... <br>
</div>
</div>
<br>
</blockquote>
<br>
<br>
I for one support this but I didn't support <a
moz-do-not-send=3D"true"
href=3D"http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf=
"
target=3D"_blank"
onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%=
2Fopen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\46sa=
\75D\46sntz\0751\46usg\75AFQjCNH8yqW-D-45bD8Vzl-z8XSa9iKp0w';return
true;"
onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fop=
en-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2014%2Fn3879.pdf\46sa\75D=
\46sntz\0751\46usg\75AFQjCNH8yqW-D-45bD8Vzl-z8XSa9iKp0w';return
true;">proposal=C2=A0N3879</a>, because of it other stuff.<br>
<br>
<br>
<div class=3D"moz-signature">-- <br>
<pre><tt>
.~. In my life God comes first....=20
/V\ but Linux is pretty high after that :-D
/( )\ Francis (Grizzly) Smit
^^-^^ <a class=3D"moz-txt-link-freetext" href=3D"http://www.smit.id.au/=
">http://www.smit.id.au/</a>
</tt><pre>
</pre></pre>
</div>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--------------020104010009040807070201--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Fri, 1 Aug 2014 21:43:04 +0200
Raw View
--089e01182d0a0b57ab04ff969998
Content-Type: text/plain; charset=UTF-8
There was a vote on the N3879 proposal as a whole and also just the break /
continue part alone:
Vote on the proposal as a whole: SF 1 - WF 1 - N 1 - WA 13 - SA 10
"break label;" + "continue label;": SF 3 - WF 8 - N 4 - WA 9 - SA 3
As you can see the break label / continue label alone didn't get enough
support. It needs to be 2/3 for to pass evolution.
Before the vote Dr Stroustrup said to the room that "we need more
complicated control structures like we need a hole in the head".
Basically he is concerned that with more complicated control structures you
can write "bad code" that is hard to read.
I decided therefore to drop this proposal.
On Fri, Aug 1, 2014 at 8:18 PM, Myriachan <myriachan@gmail.com> wrote:
> On Friday, August 1, 2014 11:13:44 AM UTC-7, Thomas Koeppe wrote:
>>
>> I believe something similar is the subject of proposal N3879
>> <http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf>, which
>> was discussed in Rapperswil. I think it did not gain a lot of support.
>>
>
> Yep, thanks. This is the proposal I was referring to where it got grouped
> up with more-controversial changes. Essentially, this is just splitting
> off the break/continue part...
>
> --
>
> ---
> 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/.
--089e01182d0a0b57ab04ff969998
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">There was a vote on the N3879 proposal as a whole and also=
just the break / continue part alone:<div><span style=3D"color:rgb(0,0,0);=
font-family:arial,verdana,sans-serif;font-size:14px;line-height:20.47499847=
4121094px"><br>
</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,verdana=
,sans-serif;font-size:14px;line-height:20.474998474121094px">=C2=A0 =C2=A0 =
Vote on the proposal as a whole: SF 1 - WF 1 - N 1 - WA 13 - SA 10</span><b=
r></div>
<div><p style=3D"margin:1em 0px 0px;color:rgb(0,0,0);font-family:arial,verd=
ana,sans-serif;font-size:14px;line-height:20.474998474121094px">=C2=A0 =C2=
=A0 "break label;" + "continue label;": SF 3 - WF 8 - N=
4 - WA 9 - SA 3</p>
<p style=3D"margin:1em 0px 0px;color:rgb(0,0,0);font-family:arial,verdana,s=
ans-serif;font-size:14px;line-height:20.474998474121094px">As you can see t=
he break label / continue label alone didn't get enough support. =C2=A0=
It needs to be 2/3 for to pass evolution.</p>
<p style=3D"margin:1em 0px 0px;color:rgb(0,0,0);font-family:arial,verdana,s=
ans-serif;font-size:14px;line-height:20.474998474121094px">Before the vote =
Dr Stroustrup said to the room that "we need more complicated control =
structures like we need a hole in the head".</p>
<p style=3D"margin:1em 0px 0px;color:rgb(0,0,0);font-family:arial,verdana,s=
ans-serif;font-size:14px;line-height:20.474998474121094px">Basically he is =
concerned that with more complicated control structures you can write "=
;bad code" that is hard to read.</p>
<p style=3D"margin:1em 0px 0px;color:rgb(0,0,0);font-family:arial,verdana,s=
ans-serif;font-size:14px;line-height:20.474998474121094px">I decided theref=
ore to drop this proposal.</p><p style=3D"margin:1em 0px 0px;color:rgb(0,0,=
0);font-family:arial,verdana,sans-serif;font-size:14px;line-height:20.47499=
8474121094px">
<br></p></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=
quote">On Fri, Aug 1, 2014 at 8:18 PM, Myriachan <span dir=3D"ltr"><<a h=
ref=3D"mailto:myriachan@gmail.com" target=3D"_blank">myriachan@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 class=3D"">On Friday, =
August 1, 2014 11:13:44 AM UTC-7, Thomas Koeppe 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">I believe something similar is the subject of <a href=3D"h=
ttp://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3879.pdf" target=3D"_bl=
ank">proposal=C2=A0N3879</a>, which was discussed in Rapperswil. I think it=
did not gain a lot of support.</div>
</blockquote></div><div><br>Yep, thanks.=C2=A0 This is the proposal I was r=
eferring to where it got grouped up with more-controversial changes.=C2=A0 =
Essentially, this is just splitting off the break/continue part... <br></di=
v></div>
<div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e01182d0a0b57ab04ff969998--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 07:00:21 +0800
Raw View
--Apple-Mail=_2D7CA728-B35B-4E5C-8627-1F106CE57C2F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 3:43 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Basically he is concerned that with more complicated control structures y=
ou can write "bad code" that is hard to read.
I disagree, and I think that repetitive exposure to such an idea will make =
it gradually seem less complicated.
Only the political tack needs adjustment. Let the thrust of the motivation =
be the simplification it provides to the user and to the optimizer (vs. int=
roducing a variable to the loop condition). Should be only a matter of sear=
ching a code base for "goto," since such break surrogates make a large prop=
ortion of goto usage.
> I decided therefore to drop this proposal.
Thanks for letting us know! Hopefully someone else will pick it up.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_2D7CA728-B35B-4E5C-8627-1F106CE57C2F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 3:43 AM, Andrew Tomazos <<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div>=
<p style=3D"margin: 1em 0px 0px; font-family: arial, verdana, sans-serif; f=
ont-size: 14px; line-height: 20.474998474121094px;">Basically he is concern=
ed that with more complicated control structures you can write "bad code" t=
hat is hard to read.</p></div></div></blockquote><div><br></div>I disagree,=
and I think that repetitive exposure to such an idea will make it graduall=
y seem less complicated.</div><div><br></div><div>Only the political tack n=
eeds adjustment. Let the thrust of the motivation be the simplification it =
provides to the user and to the optimizer (vs. introducing a variable to th=
e loop condition). Should be only a matter of searching a code base for &ld=
quo;<font face=3D"Courier">goto</font>,” since such <font face=3D"Cou=
rier">break</font> surrogates make a large proportion of <font face=3D"Cour=
ier">goto</font> usage.<br><blockquote type=3D"cite"><div dir=3D"ltr"><div>=
<p style=3D"margin: 1em 0px 0px; font-family: arial, verdana, sans-serif; f=
ont-size: 14px; line-height: 20.474998474121094px;">I decided therefore to =
drop this proposal.</p></div></div></blockquote><br></div><div>Thanks for l=
etting us know! Hopefully someone else will pick it up.</div><br></body></h=
tml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_2D7CA728-B35B-4E5C-8627-1F106CE57C2F--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 1 Aug 2014 17:19:19 -0700 (PDT)
Raw View
------=_Part_1257_1916678382.1406938759178
Content-Type: text/plain; charset=UTF-8
> Before the vote Dr Stroustrup said to the room that "we need more
complicated control structures like we need a hole in the head".
He obviously hasn't seen the boatload of terrible hacks and work-arounds
people use due to the lack of this facility. :)
--
---
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_1257_1916678382.1406938759178
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">> <span style=3D"color: rgb(0, 0, 0); font-family:=
arial, verdana, sans-serif; font-size: 14px; line-height: 20.4749984741210=
94px;">Before the vote Dr Stroustrup said to the room that "we need more co=
mplicated control structures like we need a hole in the head".</span><div><=
font color=3D"#000000" face=3D"arial, verdana, sans-serif"><span style=3D"f=
ont-size: 14px; line-height: 20.474998474121094px;"><br></span></font></div=
><div><font color=3D"#000000" face=3D"arial, verdana, sans-serif"><span sty=
le=3D"font-size: 14px; line-height: 20.474998474121094px;">He obviously has=
n't seen the boatload of terrible hacks and work-arounds people use due to =
the lack of this facility. :)</span></font></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1257_1916678382.1406938759178--
.
Author: gmisocpp@gmail.com
Date: Fri, 1 Aug 2014 20:32:30 -0700 (PDT)
Raw View
------=_Part_1407_115479152.1406950350745
Content-Type: text/plain; charset=UTF-8
On Saturday, August 2, 2014 7:43:05 AM UTC+12, Andrew Tomazos wrote:
>
> There was a vote on the N3879 proposal as a whole and also just the break
> / continue part alone:
>
> Vote on the proposal as a whole: SF 1 - WF 1 - N 1 - WA 13 - SA 10
>
> "break label;" + "continue label;": SF 3 - WF 8 - N 4 - WA 9 - SA 3
>
> As you can see the break label / continue label alone didn't get enough
> support. It needs to be 2/3 for to pass evolution.
>
> Before the vote Dr Stroustrup said to the room that "we need more
> complicated control structures like we need a hole in the head".
>
> Basically he is concerned that with more complicated control structures
> you can write "bad code" that is hard to read.
>
> I decided therefore to drop this proposal.
>
>
>
>
I can't see any great grounds for objection to labelled break/continue
statements myself except that I have rarely ever needed such power.Is it
really that common a problem to warrant it?
An interesting thing might be to search how often the feature is actually
used in java code, but quite how you do that I don't know, but people seem
to estimate these things.
Regarding the other proposal, I would have liked to see case statements
become a scope or something. I hate writing:
case 1:
int x = 0;
break;
and then getting a compiler error about x and then having to add braces
only to see that don't gel well layout wise.
Did that idea not fly either?
That IS something that bites me often.
--
---
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_1407_115479152.1406950350745
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, August 2, 2014 7:43:05 AM UTC+12, And=
rew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">There was a=
vote on the N3879 proposal as a whole and also just the break / continue p=
art alone:<div><span style=3D"color: rgb(0, 0, 0); line-height: 20.47px; fo=
nt-family: arial,verdana,sans-serif; font-size: 14px;"><br>
</span></div><div><span style=3D"color: rgb(0, 0, 0); line-height: 20.47px;=
font-family: arial,verdana,sans-serif; font-size: 14px;"> Vot=
e on the proposal as a whole: SF 1 - WF 1 - N 1 - WA 13 - SA 10</span><br><=
/div>
<div><p style=3D"margin: 1em 0px 0px; color: rgb(0, 0, 0); line-height: 20.=
47px; font-family: arial,verdana,sans-serif; font-size: 14px;">  =
; "break label;" + "continue label;": SF 3 - WF 8 - N 4 - WA 9 - SA 3</p>
<p style=3D"margin: 1em 0px 0px; color: rgb(0, 0, 0); line-height: 20.47px;=
font-family: arial,verdana,sans-serif; font-size: 14px;">As you can see th=
e break label / continue label alone didn't get enough support. It ne=
eds to be 2/3 for to pass evolution.</p>
<p style=3D"margin: 1em 0px 0px; color: rgb(0, 0, 0); line-height: 20.47px;=
font-family: arial,verdana,sans-serif; font-size: 14px;">Before the vote D=
r Stroustrup said to the room that "we need more complicated control struct=
ures like we need a hole in the head".</p>
<p style=3D"margin: 1em 0px 0px; color: rgb(0, 0, 0); line-height: 20.47px;=
font-family: arial,verdana,sans-serif; font-size: 14px;">Basically he is c=
oncerned that with more complicated control structures you can write "bad c=
ode" that is hard to read.</p>
<p style=3D"margin: 1em 0px 0px; color: rgb(0, 0, 0); line-height: 20.47px;=
font-family: arial,verdana,sans-serif; font-size: 14px;">I decided therefo=
re to drop this proposal.</p><p style=3D"margin: 1em 0px 0px; color: rgb(0,=
0, 0); line-height: 20.47px; font-family: arial,verdana,sans-serif; font-s=
ize: 14px;">
<br></p></div></div><div><br></div></blockquote><div><br></div><div><div>I =
can't see any great grounds for objection to labelled break/continue s=
tatements myself except that I have rarely ever needed such power.Is i=
t really that common a problem to warrant it?</div><div><br></div><div>An i=
nteresting thing might be to search how often the feature is actually =
used in java code, but quite how you do that I don't know, but people seem =
to estimate these things.</div><div><br></div><div>Regarding the other prop=
osal, I would have liked to see case statements become a scope or something=
.. I hate writing:</div><div>case 1:</div><div>int x =3D 0;</div><div>=
break;</div><div><br></div><div>and then getting a compiler error about x a=
nd then having to add braces only to see that don't gel well layout wise.</=
div><div>Did that idea not fly either?</div><div><br></div><div>That I=
S something that bites me often.</div> </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1407_115479152.1406950350745--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 11:43:13 +0800
Raw View
--Apple-Mail=_93E118E5-CF54-482C-BEDD-78496F957EA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 11:32 AM, gmisocpp@gmail.com wrote:
> case 1:
> int x =3D 0;
> break;
>=20
> and then getting a compiler error about x and then having to add braces o=
nly to see that don't gel well layout wise.
> Did that idea not fly either?
>=20
> That IS something that bites me often.
Is a required-diagnosis error really "getting bitten"?
Getting rid of that error -- adding virtual braces -- would require ending =
the scope of an initialized variable at the first label that would skip its=
initialization. It is allowed to jump over trivial initializations (or onl=
y scalar default initializations, I don't recall), so the scope of the vari=
able would then depend on whether it's initialized and the location of the =
label. After the label, that name would be found in an enclosing scope inst=
ead.
Which bites harder?
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_93E118E5-CF54-482C-BEDD-78496F957EA4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 11:32 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmiso=
cpp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr">case 1:<br><d=
iv><div>int x =3D 0;</div><div>break;</div><div><br></div><div>and th=
en getting a compiler error about x and then having to add braces only to s=
ee that don't gel well layout wise.</div><div>Did that idea not fly either?=
</div><div><br></div><div>That IS something that bites me often.</div>=
</div></div></div></blockquote><div><br></div><div>Is a required-diagnosis =
error really “getting bitten”?</div><div><br></div><div>Getting=
rid of that error — adding virtual braces — would require endi=
ng the scope of an initialized variable at the first label that would skip =
its initialization. It is allowed to jump over trivial initializations (or =
only scalar default initializations, I don’t recall), so the scope of=
the variable would then depend on whether it’s initialized and the l=
ocation of the label. After the label, that name would be found in an enclo=
sing scope instead.</div></div><br><div>Which bites harder?</div><div><br><=
/div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_93E118E5-CF54-482C-BEDD-78496F957EA4--
.
Author: gmisocpp@gmail.com
Date: Fri, 1 Aug 2014 21:10:04 -0700 (PDT)
Raw View
------=_Part_1434_1202906907.1406952604767
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi
On Saturday, August 2, 2014 3:43:30 PM UTC+12, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9302, at 11:32 AM, gmis...@gmail.com <javascript=
:> wrote:
>
> case 1:
> int x =3D 0;
> break;
>
> and then getting a compiler error about x and then having to add braces=
=20
> only to see that don't gel well layout wise.
> Did that idea not fly either?
>
> That IS something that bites me often.
>
>
> Is a required-diagnosis error really =E2=80=9Cgetting bitten=E2=80=9D?
>
> Getting rid of that error =E2=80=94 adding virtual braces =E2=80=94 would=
require ending=20
> the scope of an initialized variable at the first label that would skip i=
ts=20
> initialization. It is allowed to jump over trivial initializations (or on=
ly=20
> scalar default initializations, I don=E2=80=99t recall), so the scope of =
the=20
> variable would then depend on whether it=E2=80=99s initialized and the lo=
cation of=20
> the label. After the label, that name would be found in an enclosing scop=
e=20
> instead.
>
> Which bites harder?
>
I can't quite visualise what you mean. You see what I'm trying to reach=20
for though, don't you? Quite what it takes in terms of deprecation,=20
breakage or whatever to get there, I don't know. It seemed to me Andrew's=
=20
paper was aiming at what I was after in that department, but maybe it=20
wasn't. It seemed to reflect what a new user to C++ would expect from=20
switch statements.
--=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_1434_1202906907.1406952604767
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Saturday, August 2, 2014 3:43:30 PM UTC+12, D=
avid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap:=
break-word;"><br><div><div>On 2014=E2=80=9308=E2=80=9302, at 11:32 AM, <a =
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"PiEbVCv5hKsJ">gmis...@gmail.com</a> wrote:</div><br><bl=
ockquote type=3D"cite"><div style=3D"font: 12px/normal Helvetica; text-tran=
sform: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; w=
hite-space: normal; font-size-adjust: none; font-stretch: normal;"><div dir=
=3D"ltr">case 1:<br><div><div>int x =3D 0;</div><div>break;</div><div=
><br></div><div>and then getting a compiler error about x and then having t=
o add braces only to see that don't gel well layout wise.</div><div>Did tha=
t idea not fly either?</div><div><br></div><div>That IS something that=
bites me often.</div></div></div></div></blockquote><div><br></div><div>Is=
a required-diagnosis error really =E2=80=9Cgetting bitten=E2=80=9D?</div><=
div><br></div><div>Getting rid of that error =E2=80=94 adding virtual brace=
s =E2=80=94 would require ending the scope of an initialized variable at th=
e first label that would skip its initialization. It is allowed to jump ove=
r trivial initializations (or only scalar default initializations, I don=E2=
=80=99t recall), so the scope of the variable would then depend on whether =
it=E2=80=99s initialized and the location of the label. After the label, th=
at name would be found in an enclosing scope instead.</div></div><br><div>W=
hich bites harder?</div></div></blockquote><div><br></div><div>I can't =
; quite visualise what you mean. You see what I'm trying to reach for thoug=
h, don't you? Quite what it takes in terms of deprecation, breakage or what=
ever to get there, I don't know. It seemed to me Andrew's paper was aiming =
at what I was after in that department, but maybe it wasn't. It seemed to r=
eflect what a new user to C++ would expect from switch statements.</di=
v><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1434_1202906907.1406952604767--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 12:28:45 +0800
Raw View
--Apple-Mail=_65AF4096-2DDF-4BF1-AFFB-67E341FDCFFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 12:10 PM, gmisocpp@gmail.com wrote:
> On Saturday, August 2, 2014 3:43:30 PM UTC+12, David Krauss wrote:
>=20
> Getting rid of that error -- adding virtual braces -- would require endin=
g the scope of an initialized variable at the first label that would skip i=
ts initialization. It is allowed to jump over trivial initializations (or o=
nly scalar default initializations, I don't recall), so the scope of the va=
riable would then depend on whether it's initialized and the location of th=
e label. After the label, that name would be found in an enclosing scope in=
stead.
>=20
> Which bites harder?
>=20
> I can't quite visualise what you mean.
You want to be able to jump over the definition of x, but not use it after =
the jump, instead maybe declaring a different x. That essentially means the=
scope of x ends at the next case label (or any other label).
But some non-initializing definitions can be jumped over.
switch ( n ) {
case 1:
int x;
x =3D 0;
break;
case 2: // OK, x was not initialized in its definition.
int y =3D 0;
x =3D 3; // same x as declared above
break;
case 3: ; // illegal: skips initialization of y
}
Adding implicit braces would break this, even if you defined what's suppose=
d to happen when the case label is in a nested compound-statement.
> You see what I'm trying to reach for though, don't you? Quite what it tak=
es in terms of deprecation, breakage or whatever to get there, I don't know=
.. It seemed to me Andrew's paper was aiming at what I was after in that dep=
artment, but maybe it wasn't. It seemed to reflect what a new user to C++ w=
ould expect from switch statements.
I don't recall all of it, but it was pretty ambitious.
I think new C++ users should be discouraged from using switch, and that's p=
retty much the end of it. Someone who might forget the braces, might forget=
the break. Compilers today are good enough to turn an if-else if sequence =
into a lookup table, so the micro-optimization argument has gone away if it=
ever really carried weight in the first place.
On the other hand, C++ has no other facility for computed goto, so anything=
that neuters switch will considerably reduce the expressive power of the l=
anguage, for those of us who aren't making mistakes.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_65AF4096-2DDF-4BF1-AFFB-67E341FDCFFE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 12:10 PM, <a href=3D"mailto:gmisocpp@gmail.com">gmiso=
cpp@gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div style=3D"f=
ont-family: Helvetica; font-size: 12px; font-style: normal; font-variant: n=
ormal; font-weight: normal; letter-spacing: normal; line-height: normal; or=
phans: auto; text-align: start; text-indent: 0px; text-transform: none; whi=
te-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-widt=
h: 0px;"><div dir=3D"ltr">On Saturday, August 2, 2014 3:43:30 PM UTC+12, Da=
vid Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid; position: static; z-index: aut=
o;"><br><div><div>Getting rid of that error — adding virtual braces &=
mdash; would require ending the scope of an initialized variable at the fir=
st label that would skip its initialization. It is allowed to jump over tri=
vial initializations (or only scalar default initializations, I don’t=
recall), so the scope of the variable would then depend on whether it&rsqu=
o;s initialized and the location of the label. After the label, that name w=
ould be found in an enclosing scope instead.</div></div><br><div>Which bite=
s harder?</div></blockquote><div><br></div><div>I can't quite visuali=
se what you mean.</div></div></div></blockquote><div><br></div><div>You wan=
t to be able to jump over the definition of x, but not use it after the jum=
p, instead maybe declaring a different x. That essentially means the scope =
of x ends at the next case label (or any other label).</div><div><br></div>=
<div>But some non-initializing definitions can be jumped over.</div><div><b=
r></div><div><font face=3D"Courier">switch ( n ) {</font></div><div><font f=
ace=3D"Courier">case 1:</font></div><div><font face=3D"Courier"> &nbs=
p; int x;</font></div><div><font face=3D"Courier"> x =3D 0;</f=
ont></div><div><font face=3D"Courier"> break;</font></div><div=
><font face=3D"Courier"><br></font></div><div><font face=3D"Courier">case 2=
: // OK, x was not initialized in its definition.</font></div><div><font fa=
ce=3D"Courier"> int y =3D 0;</font></div><div><font face=3D"Co=
urier"> x =3D 3; // same x as declared above</font></div><div>=
<font face=3D"Courier"> break;</font></div><div><font face=3D"=
Courier"><br></font></div><div><font face=3D"Courier">case 3: ; // illegal:=
skips initialization of y</font></div><div><font face=3D"Courier">}</font>=
</div><div><br></div><div>Adding implicit braces would break this, even if =
you defined what’s supposed to happen when the case label is in a nes=
ted compound-statement.</div><br><blockquote type=3D"cite"><div style=3D"fo=
nt-family: Helvetica; font-size: 12px; font-style: normal; font-variant: no=
rmal; font-weight: normal; letter-spacing: normal; line-height: normal; orp=
hans: auto; text-align: start; text-indent: 0px; text-transform: none; whit=
e-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width=
: 0px;"><div dir=3D"ltr"><div> You see what I'm trying to reach for though,=
don't you? Quite what it takes in terms of deprecation, breakage or whatev=
er to get there, I don't know. It seemed to me Andrew's paper was aiming at=
what I was after in that department, but maybe it wasn't. It seemed to ref=
lect what a new user to C++ would expect from switch statements.</div>=
</div></div></blockquote><div><br></div></div>I don’t recall all of i=
t, but it was pretty ambitious.<div><br></div><div>I think new C++ users sh=
ould be discouraged from using <font face=3D"Courier">switch</font>, a=
nd that’s pretty much the end of it. Someone who might forget the bra=
ces, might forget the <font face=3D"Courier">break</font>. Compilers today =
are good enough to turn an if-else if sequence into a lookup table, so the =
micro-optimization argument has gone away if it ever really carried weight =
in the first place.<div><br></div><div>On the other hand, C++ has no other =
facility for computed <font face=3D"Courier">goto</font>, so anything that =
neuters <font face=3D"Courier">switch</font> will considerably reduce =
the expressive power of the language, for those of us who aren’t maki=
ng mistakes.</div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_65AF4096-2DDF-4BF1-AFFB-67E341FDCFFE--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 2 Aug 2014 08:02:01 +0300
Raw View
On 2 August 2014 02:00, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9302, at 3:43 AM, Andrew Tomazos <andrewtomazos@=
gmail.com> wrote:
>
> Basically he is concerned that with more complicated control structures y=
ou
> can write "bad code" that is hard to read.
>
>
> I disagree, and I think that repetitive exposure to such an idea will mak=
e
> it gradually seem less complicated.
>
> Only the political tack needs adjustment. Let the thrust of the motivatio=
n
> be the simplification it provides to the user and to the optimizer (vs.
> introducing a variable to the loop condition). Should be only a matter of
> searching a code base for =E2=80=9Cgoto,=E2=80=9D since such break surrog=
ates make a large
> proportion of goto usage.
I fail to see what's political about it. I also fail to see the motivation
for the idea to begin with.
> I decided therefore to drop this proposal.
>
>
> Thanks for letting us know! Hopefully someone else will pick it up.
Why? To fail again?
--=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: Sat, 2 Aug 2014 08:04:19 +0300
Raw View
On 2 August 2014 03:19, Sean Middleditch <sean.middleditch@gmail.com> wrote:
>> Before the vote Dr Stroustrup said to the room that "we need more
>> complicated control structures like we need a hole in the head".
>
> He obviously hasn't seen the boatload of terrible hacks and work-arounds
> people use due to the lack of this facility. :)
That is certainly possible, but apparently the rest of the majority of the EWG
haven't seen such things either. I wasn't in the room when this paper
was processed,
but regarding "boatload of terrible hacks and work-arounds", they do
not exist, as
far as code that I have dealt with goes.
Next anecdote, please. [citation needed]
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 2 Aug 2014 08:02:54 +0200
Raw View
--20cf301fb60dbc27b004ff9f41c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 2, 2014 at 6:28 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9302, at 12:10 PM, gmisocpp@gmail.com wrote:
>
> On Saturday, August 2, 2014 3:43:30 PM UTC+12, David Krauss wrote:
>
>>
>> Getting rid of that error =E2=80=94 adding virtual braces =E2=80=94 woul=
d require ending
>> the scope of an initialized variable at the first label that would skip =
its
>> initialization. It is allowed to jump over trivial initializations (or o=
nly
>> scalar default initializations, I don=E2=80=99t recall), so the scope of=
the
>> variable would then depend on whether it=E2=80=99s initialized and the l=
ocation of
>> the label. After the label, that name would be found in an enclosing sco=
pe
>> instead.
>>
>> Which bites harder?
>>
>
> I can't quite visualise what you mean.
>
>
> You want to be able to jump over the definition of x, but not use it afte=
r
> the jump, instead maybe declaring a different x. That essentially means t=
he
> scope of x ends at the next case label (or any other label).
>
> But some non-initializing definitions can be jumped over.
>
> switch ( n ) {
> case 1:
> int x;
> x =3D 0;
> break;
>
> case 2: // OK, x was not initialized in its definition.
> int y =3D 0;
> x =3D 3; // same x as declared above
> break;
>
> case 3: ; // illegal: skips initialization of y
> }
>
This would be implemented as:
explicit switch ( n ) {
case 1:
int x =3D 0;
break;
case 2:
int y =3D 0;
int x =3D 3;
break;
case 3: ;
}
Adding implicit braces would break this, even if you defined what=E2=80=99s
> supposed to happen when the case label is in a nested compound-statement.
>
> You see what I'm trying to reach for though, don't you? Quite what it
> takes in terms of deprecation, breakage or whatever to get there, I don't
> know. It seemed to me Andrew's paper was aiming at what I was after in th=
at
> department, but maybe it wasn't. It seemed to reflect what a new user to
> C++ would expect from switch statements.
>
>
> I don=E2=80=99t recall all of it, but it was pretty ambitious.
>
> I think new C++ users should be discouraged from using switch, and that=
=E2=80=99s
> pretty much the end of it. Someone who might forget the braces, might
> forget the break. Compilers today are good enough to turn an if-else if
> sequence into a lookup table, so the micro-optimization argument has gone
> away if it ever really carried weight in the first place.
>
> On the other hand, C++ has no other facility for computed goto, so
> anything that neuters switch will considerably reduce the expressive
> power of the language, for those of us who aren=E2=80=99t making mistakes=
..
>
The two features of explicit switch proposed were (1) no implicit
fallthrough and (2) each case statement has its own block scope. This is
the same as how the C# switch statement works, and uncontroversially better
than the current switch statement.
There was agreement from Dr S and EWG that this would have been a better
design for switch, but it isn't worth having two versions in the language.
So we just have to live with the crappy 1972 B version as patched by
-Wimplicit-fallthrough and [fallthrough].
--=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/.
--20cf301fb60dbc27b004ff9f41c4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 2, 2014 at 6:28 AM, David Krauss <span dir=3D"ltr"><<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> w=
rote:<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 style=3D"word-wrap:break-word"><br><div><div><div>
On 2014=E2=80=9308=E2=80=9302, at 12:10 PM, <a href=3D"mailto:gmisocpp@gmai=
l.com" target=3D"_blank">gmisocpp@gmail.com</a> wrote:</div><br></div><bloc=
kquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size:12px;fon=
t-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal=
;line-height:normal;text-align:start;text-indent:0px;text-transform:none;wh=
ite-space:normal;word-spacing:0px">
<div dir=3D"ltr"><div>On Saturday, August 2, 2014 3:43:30 PM UTC+12, David =
Krauss wrote:</div><div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border=
-left-width:1px;border-left-style:solid">
<br><div><div>Getting rid of that error =E2=80=94 adding virtual braces =E2=
=80=94 would require ending the scope of an initialized variable at the fir=
st label that would skip its initialization. It is allowed to jump over tri=
vial initializations (or only scalar default initializations, I don=E2=80=
=99t recall), so the scope of the variable would then depend on whether it=
=E2=80=99s initialized and the location of the label. After the label, that=
name would be found in an enclosing scope instead.</div>
</div><br><div>Which bites harder?</div></blockquote><div><br></div><div>I =
can't=C2=A0 quite visualise what you mean.</div></div></div></div></blo=
ckquote><div><br></div><div>You want to be able to jump over the definition=
of x, but not use it after the jump, instead maybe declaring a different x=
.. That essentially means the scope of x ends at the next case label (or any=
other label).</div>
<div><br></div><div>But some non-initializing definitions can be jumped ove=
r.</div><div><br></div><div><font face=3D"Courier">switch ( n ) {</font></d=
iv><div><font face=3D"Courier">case 1:</font></div><div><font face=3D"Couri=
er">=C2=A0 =C2=A0 int x;</font></div>
<div><font face=3D"Courier">=C2=A0 =C2=A0 x =3D 0;</font></div><div><font f=
ace=3D"Courier">=C2=A0 =C2=A0 break;</font></div><div><font face=3D"Courier=
"><br></font></div><div><font face=3D"Courier">case 2: // OK, x was not ini=
tialized in its definition.</font></div>
<div><font face=3D"Courier">=C2=A0 =C2=A0 int y =3D 0;</font></div><div><fo=
nt face=3D"Courier">=C2=A0 =C2=A0 x =3D 3; // same x as declared above</fon=
t></div><div><font face=3D"Courier">=C2=A0 =C2=A0 break;</font></div><div><=
font face=3D"Courier"><br></font></div>
<div><font face=3D"Courier">case 3: ; // illegal: skips initialization of y=
</font></div><div><font face=3D"Courier">}</font></div></div></div></blockq=
uote><div><br></div><div>This would be implemented as:</div><div><br></div>
<div><div><font face=3D"courier new, monospace">explicit switch ( n ) {</fo=
nt></div><div><font face=3D"courier new, monospace">case 1:</font></div><di=
v><font face=3D"courier new, monospace">=C2=A0 =C2=A0 int x =3D 0;</font></=
div><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 break;</font><=
/div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">case 2:</font></div><div><font face=3D"courier =
new, monospace">=C2=A0 =C2=A0 int y =3D 0;</font></div><div><font face=3D"c=
ourier new, monospace">=C2=A0 =C2=A0 int x =3D 3;</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 break;</font></div=
><div><font face=3D"courier new, monospace"><br></font></div><div><font fac=
e=3D"courier new, monospace">case 3: ;</font></div><div><font face=3D"couri=
er new, monospace">}</font></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);bord=
er-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><=
div>
<div></div><div>Adding implicit braces would break this, even if you define=
d what=E2=80=99s supposed to happen when the case label is in a nested comp=
ound-statement.</div><div><br><blockquote type=3D"cite"><div style=3D"font-=
family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-=
weight:normal;letter-spacing:normal;line-height:normal;text-align:start;tex=
t-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir=3D"ltr"><div> You see what I'm trying to reach for though, don=
't you? Quite what it takes in terms of deprecation, breakage or whatev=
er to get there, I don't know. It seemed to me Andrew's paper was a=
iming at what I was after in that department, but maybe it wasn't. It s=
eemed to reflect what=C2=A0a new user to C++ would expect from switch state=
ments.</div>
</div></div></blockquote><div><br></div></div></div>I don=E2=80=99t recall =
all of it, but it was pretty ambitious.<div><br></div><div>I think new C++ =
users should be discouraged from using=C2=A0<font face=3D"Courier">switch</=
font>, and that=E2=80=99s pretty much the end of it. Someone who might forg=
et the braces, might forget the <font face=3D"Courier">break</font>. Compil=
ers today are good enough to turn an if-else if sequence into a lookup tabl=
e, so the micro-optimization argument has gone away if it ever really carri=
ed weight in the first place.<div>
<br></div><div>On the other hand, C++ has no other facility for computed <f=
ont face=3D"Courier">goto</font>, so anything that neuters <font face=3D"Co=
urier">switch</font>=C2=A0will considerably reduce the expressive power of =
the language, for those of us who aren=E2=80=99t making mistakes.</div>
<div></div></div></div></blockquote></div><br></div><div class=3D"gmail_ext=
ra">The two features of explicit switch proposed were (1) no implicit fallt=
hrough and (2) each case statement has its own block scope. =C2=A0This is t=
he same as how the C# switch statement works, and uncontroversially better =
than the current switch statement.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">There was a=
greement from Dr S and EWG that this would have been a better design for sw=
itch, but it isn't worth having two versions in the language. =C2=A0So =
we just have to live with the crappy 1972 B version as patched by -Wimplici=
t-fallthrough and [fallthrough].</div>
<div class=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf301fb60dbc27b004ff9f41c4--
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Sat, 2 Aug 2014 00:45:09 -0700
Raw View
On Fri, Aug 1, 2014 at 10:04 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> but regarding "boatload of terrible hacks and work-arounds", they do
> not exist, as
> far as code that I have dealt with goes.
This pattern pops up sometimes in circumstances involving file
parsing, error handling, and some kinds of searching (among others):
while (one) {
exit = false;
while (two) {
stuff();
if (should_break) {
exit = true;
break;
}
stuff();
}
if (exit) {
break;
}
other_stuff();
}
or the version decomposing it all into smaller functions with poor
code locality and awkward parameter usage (though lambdas make that
version more palatable). Or the version using exceptions
inappropriately.
The above simplifies itself nicely into:
outer: while (one) {
while (two) {
stuff();
if (should_break)
break outer;
stuff();
}
other_stuff();
}
Break-label syntax reduces complexity of control structures in such
cases. I don't know of any places I've personally seen a use for
continue-label, and given the minor extra complexities involved in
for-loops I'd be inclined to agree that they are not useful enough to
add. For clarity, I'm only talking about break-label with the label
being associated directly with an enclosing loop statement in the
current function body, not any other statements or scopes (control
statements or otherwise).
We can accomplish all this today with goto statements and some moving
of the labels, of course, but goto is vilified enough that most
engineers seem to prefer the multitudinous branching of the first
example above (if they even know that C++ has `goto`).
There's been quite a bit of talk over the years about goto and the
cases it helps rather than hurts (I'm sure you've seen this and the
referenced articles already, but for others:
http://www.stevemcconnell.com/ccgoto.htm). Many of them boil down to
cases like the above where the main problem is really just trying to
break out of a nested level or two of loops.
Again, there are alternatives (exceptions, lambdas, broken-up code,
etc.) but they all have obvious drawbacks that easily outweigh the
addition of break-label's (IMO) singular drawback of "C doesn't
already have it."
--
Sean Middleditch
http://seanmiddleditch.com
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 15:48:03 +0800
Raw View
--Apple-Mail=_B17F5A60-C643-4F79-BDF3-425744271E23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 2:02 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> This would be implemented as:
>=20
> explicit switch ( n ) {
Well, it was only an example, it doesn't actually do anything. There's no s=
ense in merely reusing a declaration for an essentially different variable,=
but a single variable might have several initialization points depending o=
n which case is taken. That is impossible without some kind of fallthrough.
Reviewing N3879, it only adjusts case semantics immediately within the brac=
es that are syntactically part of explicit switch. So this would also work:
explicit switch ( n ) {{ // extra braces
case 1:
int x;
x =3D 0;
// implicit fallthrough
case 2:
x =3D 3; // same scope, same x
}}
> The two features of explicit switch proposed were (1) no implicit fallthr=
ough and (2) each case statement has its own block scope. This is the same=
as how the C# switch statement works, and uncontroversially better than th=
e current switch statement.
Aside from a few keystrokes, it sounds like an if-else if chain would also =
be "uncontroversially better than" a switch statement. That is what folks s=
hould use, in the vast majority of cases.
switch is a computed goto. If you want computed goto, use switch. Otherwise=
, don't. Do not be tempted by a few saved keystrokes, or the novelty of som=
ething you seldom get to use.
It has exactly the same issues you would get if you tried to replace if-els=
e if with a sequence of gotos. That is the nature of the beast.
> There was agreement from Dr S and EWG that this would have been a better =
design for switch, but it isn't worth having two versions in the language. =
So we just have to live with the crappy 1972 B version as patched by -Wimp=
licit-fallthrough and [fallthrough].
It's unfortunate that switch gained popularity, and other languages (even w=
ithout goto) adopted it as a terse shorthand for if-else if (C#) or a seque=
nce of ifs associated with a break target (Java), but even a popular pig sh=
ouldn't be given lipstick treatment.
On the other hand, the same languages have recognized the utility of labele=
d loop breaks, and C++ would benefit from the same.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_B17F5A60-C643-4F79-BDF3-425744271E23
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 2:02 PM, Andrew Tomazos <<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>This would be impleme=
nted as:</div><div><br></div>
<div><div><font face=3D"courier new, monospace">explicit switch ( n ) {</fo=
nt></div></div></div></div></div></blockquote><div><br></div><div>Well, it =
was only an example, it doesn’t actually do anything. There’s n=
o sense in merely reusing a declaration for an essentially different variab=
le, but a single variable might have several initialization points dependin=
g on which case is taken. That is impossible without some kind of fallthrou=
gh.</div><div><br></div><div>Reviewing N3879, it only adjusts case semantic=
s immediately within the braces that are syntactically part of <font face=
=3D"Courier">explicit switch</font>. So this would also work:</div><div><br=
></div><div><div><font face=3D"Courier">explicit switch ( n ) {{ // extra b=
races</font></div><div><font face=3D"Courier">case 1:</font></div><div><fon=
t face=3D"Courier"> int x;</font></div><div><font face=3D"Cour=
ier"> x =3D 0;</font></div><div><font face=3D"Courier"> =
// implicit fallthrough</font></div><div><font face=3D"Courier"><br>=
</font></div><div><font face=3D"Courier">case 2:</font></div><div><span sty=
le=3D"font-family: Courier;"> x =3D 3; // same scope, same x</=
span></div><div><span style=3D"font-family: Courier;">}}</span></div><div><=
font face=3D"Courier"><br></font></div></div><br><blockquote type=3D"cite">=
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"></di=
v></div><div class=3D"gmail_extra">The two features of explicit switch prop=
osed were (1) no implicit fallthrough and (2) each case statement has its o=
wn block scope. This is the same as how the C# switch statement works=
, and uncontroversially better than the current switch statement.</div></di=
v></blockquote><div><br></div><div>Aside from a few keystrokes, it sounds l=
ike an if-else if chain would also be “uncontroversially better than&=
rdquo; a switch statement. That is what folks should use, in the vast major=
ity of cases.</div><div><br></div><div><font face=3D"Courier">switch</font>=
is a computed <font face=3D"Courier">goto</font>. If you want computed <fo=
nt face=3D"Courier">goto</font>, use <font face=3D"Courier">switch</font>. =
Otherwise, don’t. Do not be tempted by a few saved keystrokes, or the=
novelty of something you seldom get to use.</div><div><br></div><div>It ha=
s exactly the same issues you would get if you tried to replace if-else if =
with a sequence of <font face=3D"Courier">goto</font>s. That is the nature =
of the beast.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">
<div class=3D"gmail_extra">There was agreement from Dr S and EWG that this =
would have been a better design for switch, but it isn't worth having two v=
ersions in the language. So we just have to live with the crappy 1972=
B version as patched by -Wimplicit-fallthrough and [fallthrough].</div>
</div></blockquote><br></div><div>It’s unfortunate that <font face=3D=
"Courier">switch</font> gained popularity, and other languages (even withou=
t <font face=3D"Courier">goto</font>) adopted it as a terse shorthand for i=
f-else if (C#) or a sequence of <font face=3D"Courier">if</font>s associate=
d with a <font face=3D"Courier">break</font> target (Java), but even a popu=
lar pig shouldn’t be given lipstick treatment.</div><div><br></div><d=
iv>On the other hand, the same languages have recognized the utility of lab=
eled loop breaks, and C++ would benefit from the same.</div><div><br></div>=
</body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_B17F5A60-C643-4F79-BDF3-425744271E23--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 2 Aug 2014 09:58:20 +0200
Raw View
--047d7b4144788cd0b604ffa0de5c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 2, 2014 at 9:48 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9302, at 2:02 PM, Andrew Tomazos <andrewtomazos@=
gmail.com> wrote:
>
> This would be implemented as:
>
> explicit switch ( n ) {
>
>
> Well, it was only an example, it doesn=E2=80=99t actually do anything. Th=
ere=E2=80=99s no
> sense in merely reusing a declaration for an essentially different
> variable, but a single variable might have several initialization points
> depending on which case is taken. That is impossible without some kind of
> fallthrough.
>
> Reviewing N3879, it only adjusts case semantics immediately within the
> braces that are syntactically part of explicit switch. So this would also
> work:
>
> explicit switch ( n ) {{ // extra braces
> case 1:
> int x;
> x =3D 0;
> // implicit fallthrough
>
> case 2:
> x =3D 3; // same scope, same x
> }}
>
> No, it wouldn't work. That isn't a case-statement. The body of an
explicit switch must consist of a sequence of case-statements.
>
> The two features of explicit switch proposed were (1) no implicit
> fallthrough and (2) each case statement has its own block scope. This is
> the same as how the C# switch statement works, and uncontroversially bett=
er
> than the current switch statement.
>
>
> Aside from a few keystrokes, it sounds like an if-else if chain would als=
o
> be =E2=80=9Cuncontroversially better than=E2=80=9D a switch statement. Th=
at is what folks
> should use, in the vast majority of cases.
>
An if-else chain requires repeating (and/or naming) the condition, which is
ugly and stupid. Conceptually a switch is a perfectly sound structured
programming construct. It executes one of n blocks based on a condition
that has one of n states. Apart from the two design flaws in the C switch,
that is basically what it does and how it is used most of the time.
switch is a computed goto. If you want computed goto, use switch.
> Otherwise, don=E2=80=99t. Do not be tempted by a few saved keystrokes, or=
the
> novelty of something you seldom get to use.
>
It has exactly the same issues you would get if you tried to replace
> if-else if with a sequence of gotos. That is the nature of the beast.
>
> There was agreement from Dr S and EWG that this would have been a better
> design for switch, but it isn't worth having two versions in the language=
..
> So we just have to live with the crappy 1972 B version as patched by
> -Wimplicit-fallthrough and [fallthrough].
>
>
> It=E2=80=99s unfortunate that switch gained popularity, and other languag=
es (even
> without goto) adopted it as a terse shorthand for if-else if (C#) or a
> sequence of ifs associated with a break target (Java), but even a popular
> pig shouldn=E2=80=99t be given lipstick treatment.
>
> On the other hand, the same languages have recognized the utility of
> labeled loop breaks, and C++ would benefit from the same.
>
--=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/.
--047d7b4144788cd0b604ffa0de5c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On S=
at, Aug 2, 2014 at 9:48 AM, David Krauss <span dir=3D"ltr"><<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@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 style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9308=E2=80=9302, at 2:02 PM, Andrew Tom=
azos <<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andre=
wtomazos@gmail.com</a>> wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>This would be implemented as:</div><div><br>=
</div>
<div><div><font face=3D"courier new, monospace">explicit switch ( n ) {</fo=
nt></div></div></div></div></div></blockquote><div><br></div></div><div>Wel=
l, it was only an example, it doesn=E2=80=99t actually do anything. There=
=E2=80=99s no sense in merely reusing a declaration for an essentially diff=
erent variable, but a single variable might have several initialization poi=
nts depending on which case is taken. That is impossible without some kind =
of fallthrough.</div>
<div><br></div><div>Reviewing N3879, it only adjusts case semantics immedia=
tely within the braces that are syntactically part of <font face=3D"Courier=
">explicit switch</font>. So this would also work:</div><div><br></div><div=
>
<div><font face=3D"Courier">explicit switch ( n ) {{ // extra braces</font>=
</div><div class=3D""><div><font face=3D"Courier">case 1:</font></div><div>=
<font face=3D"Courier">=C2=A0 =C2=A0 int x;</font></div><div><font face=3D"=
Courier">=C2=A0 =C2=A0 x =3D 0;</font></div>
</div><div><font face=3D"Courier">=C2=A0 =C2=A0 // implicit fallthrough</fo=
nt></div><div><font face=3D"Courier"><br></font></div><div><font face=3D"Co=
urier">case 2:</font></div><div><span style=3D"font-family:Courier">=C2=A0 =
=C2=A0 x =3D 3; // same scope, same x</span></div>
<div><span style=3D"font-family:Courier">}}</span></div><div><font face=3D"=
Courier"><br></font></div></div></div></div></blockquote><div>No, it wouldn=
't work. =C2=A0That isn't a case-statement. =C2=A0The body of an ex=
plicit switch must consist of a sequence of case-statements.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:bre=
ak-word"><div><div><div><font face=3D"Courier"></font></div></div><div clas=
s=3D""><br>
<blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"></div></div><div class=3D"gmail_extra">The two featur=
es of explicit switch proposed were (1) no implicit fallthrough and (2) eac=
h case statement has its own block scope. =C2=A0This is the same as how the=
C# switch statement works, and uncontroversially better than the current s=
witch statement.</div>
</div></blockquote><div><br></div></div><div>Aside from a few keystrokes, i=
t sounds like an if-else if chain would also be =E2=80=9Cuncontroversially =
better than=E2=80=9D a switch statement. That is what folks should use, in =
the vast majority of cases.</div>
</div></div></blockquote><div><br></div><div>An if-else chain requires repe=
ating (and/or naming) the condition, which is ugly and stupid. =C2=A0Concep=
tually a switch is a perfectly sound structured programming construct. =C2=
=A0It executes one of n blocks based on a condition that has one of n state=
s. =C2=A0Apart from the two design flaws in the C switch, that is basically=
what it does and how it is used most of the time.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word"><div><div></div><div><font face=3D"Courier">switch</font> is a compu=
ted <font face=3D"Courier">goto</font>. If you want computed <font face=3D"=
Courier">goto</font>, use <font face=3D"Courier">switch</font>. Otherwise, =
don=E2=80=99t. Do not be tempted by a few saved keystrokes, or the novelty =
of something you seldom get to use.</div>
</div></div></blockquote><div><br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
style=3D"word-wrap:break-word"><div><div></div><div>It has exactly the sam=
e issues you would get if you tried to replace if-else if with a sequence o=
f <font face=3D"Courier">goto</font>s. That is the nature of the beast.</di=
v>
<div class=3D""><br><blockquote type=3D"cite"><div dir=3D"ltr">
<div class=3D"gmail_extra">There was agreement from Dr S and EWG that this =
would have been a better design for switch, but it isn't worth having t=
wo versions in the language. =C2=A0So we just have to live with the crappy =
1972 B version as patched by -Wimplicit-fallthrough and [fallthrough].</div=
>
</div></blockquote><br></div></div><div>It=E2=80=99s unfortunate that <font=
face=3D"Courier">switch</font> gained popularity, and other languages (eve=
n without <font face=3D"Courier">goto</font>) adopted it as a terse shortha=
nd for if-else if (C#) or a sequence of <font face=3D"Courier">if</font>s a=
ssociated with a <font face=3D"Courier">break</font> target (Java), but eve=
n a popular pig shouldn=E2=80=99t be given lipstick treatment.</div>
<div><br></div><div>On the other hand, the same languages have recognized t=
he utility of labeled loop breaks, and C++ would benefit from the same.</di=
v><div></div></div></blockquote></div><br></div><div class=3D"gmail_extra">
<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b4144788cd0b604ffa0de5c--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 16:00:00 +0800
Raw View
--Apple-Mail=_8B1682D0-BBC7-4C71-829C-DBAFD2B210DD
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 3:45 PM, Sean Middleditch <sean@middleditch.us> wrote:
> Break-label syntax reduces complexity of control structures in such
> cases. I don't know of any places I've personally seen a use for
> continue-label, and given the minor extra complexities involved in
> for-loops I'd be inclined to agree that they are not useful enough to
> add.
Continue-label is tricky because the equivalent goto label is at the end of the loop, not the beginning, but you cannot label a close brace.
for ( ... ) {
for ( ... ) {
if ( q ) goto continue_outer;
}
continue_outer:
; // need this semicolon!
}
That said, I can't find evidence of ever actually having done this, despite seeming to recall a 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/.
--Apple-Mail=_8B1682D0-BBC7-4C71-829C-DBAFD2B210DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 3:45 PM, Sean Middleditch <<a href=3D"mailto:sean@=
middleditch.us">sean@middleditch.us</a>> wrote:</div><br class=3D"Apple-=
interchange-newline"><blockquote type=3D"cite"><span style=3D"font-family: =
Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-=
weight: normal; letter-spacing: normal; line-height: normal; orphans: auto;=
text-align: start; text-indent: 0px; text-transform: none; white-space: no=
rmal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; floa=
t: none; display: inline !important;">Break-label syntax reduces complexity=
of control structures in such</span><br style=3D"font-family: Helvetica; f=
ont-size: 12px; font-style: normal; font-variant: normal; font-weight: norm=
al; letter-spacing: normal; line-height: normal; orphans: auto; text-align:=
start; text-indent: 0px; text-transform: none; white-space: normal; widows=
: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span style=3D"=
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px; float: none; display: inline !important;">cases. I don't know of a=
ny places I've personally seen a use for</span><br style=3D"font-family: He=
lvetica; font-size: 12px; font-style: normal; font-variant: normal; font-we=
ight: normal; letter-spacing: normal; line-height: normal; orphans: auto; t=
ext-align: start; text-indent: 0px; text-transform: none; white-space: norm=
al; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span=
style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; font=
-variant: normal; font-weight: normal; letter-spacing: normal; line-height:=
normal; orphans: auto; text-align: start; text-indent: 0px; text-transform=
: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-=
stroke-width: 0px; float: none; display: inline !important;">continue-label=
, and given the minor extra complexities involved in</span><br style=3D"fon=
t-family: Helvetica; font-size: 12px; font-style: normal; font-variant: nor=
mal; font-weight: normal; letter-spacing: normal; line-height: normal; orph=
ans: auto; text-align: start; text-indent: 0px; text-transform: none; white=
-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width:=
0px;"><span style=3D"font-family: Helvetica; font-size: 12px; font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: normal; =
line-height: normal; orphans: auto; text-align: start; text-indent: 0px; te=
xt-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px; float: none; display: inline !important;">fo=
r-loops I'd be inclined to agree that they are not useful enough to</span><=
br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;"><span style=3D"font-family: Helvetica; font-size: 12p=
x; font-style: normal; font-variant: normal; font-weight: normal; letter-sp=
acing: normal; line-height: normal; orphans: auto; text-align: start; text-=
indent: 0px; text-transform: none; white-space: normal; widows: auto; word-=
spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline =
!important;">add. </span></blockquote><div><br></div><div>Continue-la=
bel is tricky because the equivalent <font face=3D"Courier">goto</font> lab=
el is at the end of the loop, not the beginning, but you cannot label a clo=
se brace.</div><div><br></div><div><font face=3D"Courier">for ( … ) =
{</font></div><div><font face=3D"Courier"> for ( … ) {<=
/font></div><div><font face=3D"Courier"> if ( q =
) goto continue_outer;</font></div><div><font face=3D"Courier">  =
; }</font></div><div><font face=3D"Courier">continue_outer:</font></div><di=
v><font face=3D"Courier"> ; // need this semicolon!</font></di=
v><div><font face=3D"Courier">}</font></div><div><br></div><div>That said, =
I can’t find evidence of ever actually having done this, despite seem=
ing to recall a case.</div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_8B1682D0-BBC7-4C71-829C-DBAFD2B210DD--
.
Author: David Krauss <potswa@gmail.com>
Date: Sat, 2 Aug 2014 16:37:24 +0800
Raw View
--Apple-Mail=_51514EA8-DECA-45B4-B1BA-B8485380919C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-02, at 3:58 PM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> No, it wouldn't work. That isn't a case-statement. The body of an expli=
cit switch must consist of a sequence of case-statements.
Well, an unused case label would fix that. Point is, the proposed explicit =
switch can still branch to things that aren't case-statements, because "an =
explicit switch statement is a switch statement." Case labels inside case-s=
tatements look like more case-statements but they are not.
> An if-else chain requires repeating (and/or naming) the condition, which =
is ugly and stupid. =20
Named variables are stupid? Really?
The difference between repeating case status::foo: {} break; and repeating =
else if ( var =3D=3D status::foo ) {} is a few (in this case, six) keystrok=
es. Macros can provide a shortcut like that, but nobody would do so, becaus=
e there's no real value.
Using case for if-else has negligible benefit. Even if other languages do i=
t differently, or warnings exist, the argument for doing so is very weak. I=
t boils down to tradition. Dare I say, a stupid one.
It's easier to forbid switch in your own style guide than it is to "fix" it=
for everyone.
> Conceptually a switch is a perfectly sound structured programming constru=
ct. It executes one of n blocks based on a condition that has one of n sta=
tes. Apart from the two design flaws in the C switch, that is basically wh=
at it does and how it is used most of the time.
That's just what if-else if does.
It's not "basically" what switch does, because you need various decorations=
(breaks and braces) and constraints (integer or enumeration type, constant=
expressions) to make the if-else if equivalence actually happen. Basically=
or fundamentally, switch jumps to a succeeding label just like goto does.
Use the right tool for the job.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_51514EA8-DECA-45B4-B1BA-B8485380919C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–02, at 3:58 PM, Andrew Tomazos <<a href=3D"mailto:andrewt=
omazos@gmail.com">andrewtomazos@gmail.com</a>> wrote:</div><br class=3D"=
Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><div>No, it wouldn't work.=
That isn't a case-statement. The body of an explicit switch mu=
st consist of a sequence of case-statements.</div></div></div></div></block=
quote><div><br></div><div>Well, an unused case label would fix that. Point =
is, the proposed <font face=3D"Courier">explicit switch</font> can still br=
anch to things that aren’t case-statements, because “an <font f=
ace=3D"Courier">explicit switch</font> statement is a <font face=3D"Courier=
">switch</font> statement.” Case labels inside case-statements look l=
ike more case-statements but they are not.</div><br><blockquote type=3D"cit=
e"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">
<div>An if-else chain requires repeating (and/or naming) the condition, whi=
ch is ugly and stupid. </div></div></div></div></blockquote><div><br>=
</div><div>Named variables are stupid? Really?</div><div><br></div><div>The=
difference between repeating <font face=3D"Courier">case status::foo: {} b=
reak;</font> and repeating <font face=3D"Courier">else if ( var =3D=3D=
status::foo ) {}</font> is a few (in this case, six) keystrokes. Macr=
os can provide a shortcut like that, but nobody would do so, because there&=
rsquo;s no real value.</div><div><br></div><div>Using <font face=3D"Courier=
">case</font> for if-else has negligible benefit. Even if other languages d=
o it differently, or warnings exist, the argument for doing so is very weak=
.. It boils down to tradition. Dare I say, a stupid one.</div><div><br></div=
><div>It’s easier to forbid <font face=3D"Courier">switch</font> in y=
our own style guide than it is to “fix” it for everyone.</div><=
div><br></div><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><div>Conceptually a switch is a perfect=
ly sound structured programming construct. It executes one of n block=
s based on a condition that has one of n states. Apart from the two d=
esign flaws in the C switch, that is basically what it does and how it is u=
sed most of the time.</div></div></div></div></blockquote><div><br></div><d=
iv>That’s just what if-else if does.</div></div><div><br></div><div>I=
t’s not “basically” what <font face=3D"Courier">switch</f=
ont> does, because you need various decorations (breaks and braces) and con=
straints (integer or enumeration type, constant expressions) to make the if=
-else if equivalence actually happen. Basically or fundamentally, <font fac=
e=3D"Courier">switch</font> jumps to a succeeding label just like <font fac=
e=3D"Courier">goto</font> does.</div><div><br></div><div>Use the right tool=
for the job.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_51514EA8-DECA-45B4-B1BA-B8485380919C--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sat, 2 Aug 2014 10:54:14 +0200
Raw View
--20cf30363b4b7db66a04ffa1a6e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sat, Aug 2, 2014 at 10:37 AM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9308=E2=80=9302, at 3:58 PM, Andrew Tomazos <andrewtomazos@=
gmail.com> wrote:
>
> No, it wouldn't work. That isn't a case-statement. The body of an
> explicit switch must consist of a sequence of case-statements.
>
>
> Well, an unused case label would fix that. Point is, the proposed explici=
t
> switch can still branch to things that aren=E2=80=99t case-statements, be=
cause
> =E2=80=9Can explicit switch statement is a switch statement.=E2=80=9D Cas=
e labels inside
> case-statements look like more case-statements but they are not.
>
>
It's a very minor nit - I considered making case labels associated with an
explicit switch statement ill-formed if they are not the leading labels of
case-statements, but I figured it was not something people would do by
accident, so the rule would just muddy up the spec for no good reason. If
people want the old behavior it's a lot easier to just drop the explicit
specifier.
An if-else chain requires repeating (and/or naming) the condition, which is
> ugly and stupid.
>
>
> Named variables are stupid? Really?
>
> The difference between repeating case status::foo: {} break; and
> repeating else if ( var =3D=3D status::foo ) {} is a few (in this case, s=
ix)
> keystrokes. Macros can provide a shortcut like that, but nobody would do
> so, because there=E2=80=99s no real value.
>
> Using case for if-else has negligible benefit. Even if other languages do
> it differently, or warnings exist, the argument for doing so is very weak=
..
> It boils down to tradition. Dare I say, a stupid one.
>
> It=E2=80=99s easier to forbid switch in your own style guide than it is t=
o =E2=80=9Cfix=E2=80=9D
> it for everyone.
>
> Conceptually a switch is a perfectly sound structured programming
> construct. It executes one of n blocks based on a condition that has one
> of n states. Apart from the two design flaws in the C switch, that is
> basically what it does and how it is used most of the time.
>
>
> That=E2=80=99s just what if-else if does.
>
> It=E2=80=99s not =E2=80=9Cbasically=E2=80=9D what switch does, because yo=
u need various
> decorations (breaks and braces) and constraints (integer or enumeration
> type, constant expressions) to make the if-else if equivalence actually
> happen. Basically or fundamentally, switch jumps to a succeeding label
> just like goto does.
>
> Use the right tool for the job.
>
--=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/.
--20cf30363b4b7db66a04ffa1a6e6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Sat, Aug 2, 2014 at 10:37 AM, David Krauss <span dir=3D"ltr"><=
;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@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 style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9308=E2=80=9302, at 3:58 PM, Andrew Tom=
azos <<a href=3D"mailto:andrewtomazos@gmail.com" target=3D"_blank">andre=
wtomazos@gmail.com</a>> wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra"><=
div class=3D"gmail_quote"><div>No, it wouldn't work. =C2=A0That isn'=
;t a case-statement. =C2=A0The body of an explicit switch must consist of a=
sequence of case-statements.</div>
</div></div></div></blockquote><div><br></div></div><div>Well, an unused ca=
se label would fix that. Point is, the proposed <font face=3D"Courier">expl=
icit switch</font> can still branch to things that aren=E2=80=99t case-stat=
ements, because =E2=80=9Can <font face=3D"Courier">explicit switch</font> s=
tatement is a <font face=3D"Courier">switch</font> statement.=E2=80=9D Case=
labels inside case-statements look like more case-statements but they are =
not.</div>
<div class=3D""><br></div></div></div></blockquote><div><br></div><div>It&#=
39;s a very minor nit - I considered making case labels associated with an =
explicit switch statement ill-formed if they are not the leading labels of =
case-statements, but I figured it was not something people would do by acci=
dent, so the rule would just muddy up the spec for no good reason. =C2=A0If=
people want the old behavior it's a lot easier to just drop the explic=
it specifier.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break=
-word"><div><div class=3D""><blockquote type=3D"cite"><div dir=3D"ltr"><div=
class=3D"gmail_extra">
<div class=3D"gmail_quote">
<div>An if-else chain requires repeating (and/or naming) the condition, whi=
ch is ugly and stupid. =C2=A0</div></div></div></div></blockquote><div><br>=
</div></div><div>Named variables are stupid? Really?</div><div><br></div><d=
iv>
The difference between repeating <font face=3D"Courier">case status::foo: {=
} break;</font>=C2=A0and repeating <font face=3D"Courier">else if ( var =3D=
=3D status::foo ) {}</font>=C2=A0is a few (in this case, six) keystrokes. M=
acros can provide a shortcut like that, but nobody would do so, because the=
re=E2=80=99s no real value.</div>
<div><br></div><div>Using <font face=3D"Courier">case</font> for if-else ha=
s negligible benefit. Even if other languages do it differently, or warning=
s exist, the argument for doing so is very weak. It boils down to tradition=
.. Dare I say, a stupid one.</div>
<div><br></div><div>It=E2=80=99s easier to forbid <font face=3D"Courier">sw=
itch</font> in your own style guide than it is to =E2=80=9Cfix=E2=80=9D it =
for everyone.</div><div class=3D""><div><br></div><blockquote type=3D"cite"=
><div dir=3D"ltr"><div class=3D"gmail_extra">
<div class=3D"gmail_quote"><div>Conceptually a switch is a perfectly sound =
structured programming construct. =C2=A0It executes one of n blocks based o=
n a condition that has one of n states. =C2=A0Apart from the two design fla=
ws in the C switch, that is basically what it does and how it is used most =
of the time.</div>
</div></div></div></blockquote><div><br></div></div><div>That=E2=80=99s jus=
t what if-else if does.</div></div><div><br></div><div>It=E2=80=99s not =E2=
=80=9Cbasically=E2=80=9D what <font face=3D"Courier">switch</font> does, be=
cause you need various decorations (breaks and braces) and constraints (int=
eger or enumeration type, constant expressions) to make the if-else if equi=
valence actually happen. Basically or fundamentally, <font face=3D"Courier"=
>switch</font> jumps to a succeeding label just like <font face=3D"Courier"=
>goto</font> does.</div>
<div><br></div><div>Use the right tool for the job.</div><div></div></div><=
/blockquote></div><br></div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra"><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--20cf30363b4b7db66a04ffa1a6e6--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Sat, 2 Aug 2014 09:19:41 -0700 (PDT)
Raw View
------=_Part_895_38180572.1406996382019
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Regarding labelled breaks, this is something I miss in the language=E2=80=
=94I quite=20
often have to write code that needs to break out of an outer loop after a=
=20
successful search, and any method I can currently envisage to do this are=
=20
horrible hacks!!!
I cannot see what is wrong with switch statements. If you have a dozen=20
different alternatives which need different code, having if (=E2=80=A6) els=
e if (=E2=80=A6)=20
else =E2=80=A6 is horrible, not to mention the complications for verifying=
=20
correctness.
To David, I can only say,
=E2=80=9CUse the right tool for the job.=E2=80=9D
--=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_895_38180572.1406996382019
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Regarding labelled breaks, this is something I miss in the=
language=E2=80=94I quite often have to write code that needs to break out =
of an outer loop after a successful search, and any method I can currently =
envisage to do this are horrible hacks!!!<br><br>I cannot see what is wrong=
with switch statements. If you have a dozen different alternatives w=
hich need different code, having if (=E2=80=A6) else if (=E2=80=A6) else =
=E2=80=A6 is horrible, not to mention the complications for verifying corre=
ctness.<br><br>To David, I can only say,<br><br>=E2=80=9CUse the right tool=
for the job.=E2=80=9D<div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_895_38180572.1406996382019--
.
Author: Jim Porter <jvp4846@g.rit.edu>
Date: Sat, 02 Aug 2014 13:55:02 -0500
Raw View
On 8/2/2014 11:19 AM, Douglas Boffey wrote:
> Regarding labelled breaks, this is something I miss in the language=E2=80=
=94I
> quite often have to write code that needs to break out of an outer loop
> after a successful search, and any method I can currently envisage to do
> this are horrible hacks!!!
It's not clear to me how a goto constitutes a "horrible hack" in this=20
case. break and continue are just gotos with an implicit label anyway.=20
If you go through the effort to label your controls structures so you=20
can use named break/continue, you really haven't gained much from just=20
using a goto.
About the only benefits I can see are 1) the label goes in a slightly=20
more obvious place, and 2) the compiler could emit some possibly-useful=20
diagnostics (e.g. to make sure you don't goto a label that's part of an=20
unrelated loop).
While I don't actively opposed labeled break/continue, the benefits=20
don't outweigh the costs of implementation in my opinion. (Also, if this=20
*were* standardized, I'd much rather see it standardized in C first, and=20
then have C++ follow along.)
- Jim
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 3 Aug 2014 10:18:58 +0800
Raw View
--Apple-Mail=_23178F56-5992-443B-B4B0-DC405C92211A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-03, at 12:19 AM, Douglas Boffey <douglas.boffey@gmail.com> wrote=
:
> I cannot see what is wrong with switch statements. If you have a dozen d=
ifferent alternatives which need different code, having if (...) else if (.=
...) else ... is horrible, not to mention the complications for verifying co=
rrectness.
>=20
> To David, I can only say,
>=20
> "Use the right tool for the job."
Let's quantify the benefits to switch for mutually exclusive cases:
1. The compiler must detect a repeated value.
2. The compiler may detect a missing enumerator.
3. You cannot accidentally test a different variable.
4. Avoiding repetition of a variable name is terser.
(But aside from the name, switch is usually more verbose, and this verbosit=
y is not expressive, but just a magic spell that must be remembered.)
#1-#2 are is the only ones worth mentioning IMHO. I can't think what else y=
ou mean by "complications for verifying correctness," since switch can othe=
rwise only introduce control flow errors.
Is it easier to change the semantics of switch to guarantee if-else if cont=
rol flow, or to add a the value checks to an if-else ladder? That can be do=
ne with an attribute.
[[dispatch]] // This will be a ladder with a common variable and mutually e=
xclusive constants.
if ( var =3D=3D status::foo ) {
} else if ( var =3D=3D status::foo ) { // Optional diagnosis: repeated cons=
tant.
} else if ( var + 1 =3D=3D status::bar ) { // Optional diagnosis: different=
variable (#3).
} // Optional diagnosis: missing enumerator.
This would already work with non-integer literal types and tests besides eq=
uality, for example prioritized bitset intersection and floating-point ineq=
ualities. (The examples below show such, but that part applies to the above=
..) It's also extensible. My code often cannot benefit from the enumerator c=
heck, because I'll extend a public enumeration interface with some private =
values for internal usage. The attribute expresses that something should be=
checked right there; it's not just a heuristic about most programmers and =
most switches, controlled by a global warning switch.
int var =3D thing.state;
[[dispatch (enum status, enum impl_state)]] // Explicitly describe what to =
check
if ( var =3D=3D status::foo ) {
} else if ( var =3D=3D impl_state::in_process ) {
} // Diagnose missing enumerators from multiple enumerations.
If we're hellbent on saving keystrokes (#4), a stronger extension can do th=
at, still easier and more productive than neutering switch. Introduce the c=
ase-else statement, which can only appear in the else clause of an if-else =
statement whose condition is a binary expression with a constant expression=
on one side, or the else clause of another case-else statement. The case s=
tatement simply replaces the constant expression part of its parent if.
if ( num < 0.5 ) {
} else case ( 1.3 ) { // OK, like "else if ( num < 1.3 )"
} else case ( 0.8 ) { // optional diagnosis
}
enum class flags {
zip =3D 1,
buzz =3D 3,
zap =3D 5
};
if ( bits & flags::zip ) {
} else case ( flags::buzz ) { // OK, condition is ( bits & flags::buzz )
} // optional diagnosis: bit-value 4 not covered
I'm not very serious about these proposals, but they're more than strawmen.=
So what's the point?
1. An extension should pick a starting point close to the finish line. If-e=
lse already has the semantics we want, but switch is how most existing disp=
atcher code is written. This is a dilemma, but think about the balance. Is =
it so essential to reduce the opt-in barrier to a single keyword, that othe=
r applications should be ignored, which are exposed by the things if-else a=
lready does?
2. Erasing break statements (remember, they're just like gotos) and adding =
braces as part of the opt-in process are a tangible simplification. It nice=
ly normalizes the code and eliminates the need to teach the weirdness of sw=
itch, along with usage of switch itself. That's the exact opposite of horri=
ble.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_23178F56-5992-443B-B4B0-DC405C92211A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–03, at 12:19 AM, Douglas Boffey <<a href=3D"mailto:dougla=
s.boffey@gmail.com">douglas.boffey@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I=
cannot see what is wrong with switch statements. If you have a dozen=
different alternatives which need different code, having if (…) els=
e if (…) else … is horrible, not to mention the complications=
for verifying correctness.<br><br>To David, I can only say,<br><br>“=
Use the right tool for the job.”</div></blockquote><div><br></div></d=
iv>Let’s quantify the benefits to <font face=3D"Courier">switch<=
/font> for mutually exclusive cases:<div><br></div><div>1. The compile=
r must detect a repeated value.</div><div>2. The compiler may detect a miss=
ing enumerator.</div><div>3. You cannot accidentally test a different varia=
ble.</div><div>4. Avoiding repetition of a variable name is terser.</div><d=
iv>(But aside from the name, <font face=3D"Courier">switch</font> is usuall=
y more verbose, and this verbosity is not expressive, but just a magic spel=
l that must be remembered.)</div><div><br></div><div>#1-#2 are is the only =
ones worth mentioning IMHO. I can’t think what else you mean by &ldqu=
o;complications for verifying correctness,” since switch can otherwis=
e only introduce control flow errors.</div><div><br></div><div>Is it easier=
to change the semantics of switch to guarantee if-else if control flow, or=
to add a the value checks to an if-else ladder? That can be done with an a=
ttribute.</div><div><br></div><div><font face=3D"Courier">[[dispatch]] // T=
his will be a ladder with a common variable and mutually exclusive constant=
s.</font></div><div><font face=3D"Courier">if ( var =3D=3D status::foo ) {<=
/font></div><div><font face=3D"Courier">} else if ( var =3D=3D status::foo =
) { // Optional diagnosis: repeated constant.</font></div><div><font face=
=3D"Courier">} else if ( var + 1 =3D=3D status::bar ) { // Optional diagnos=
is: different variable (#3).</font></div><div><font face=3D"Courier">} // O=
ptional diagnosis: missing enumerator.</font></div><div><br></div><div>This=
would already work with non-integer literal types and tests besides equali=
ty, for example prioritized bitset intersection and floating-point inequali=
ties. (The examples below show such, but that part applies to the above.) I=
t’s also extensible. My code often cannot benefit from the enumerator=
check, because I’ll extend a public enumeration interface with some =
private values for internal usage. The attribute expresses that something s=
hould be checked right there; it’s not just a heuristic about most pr=
ogrammers and most switches, controlled by a global warning switch.</div><d=
iv><br></div><div><font face=3D"Courier">int var =3D thing.state;</font></d=
iv><div><font face=3D"Courier"><br></font></div><div><div><font face=3D"Cou=
rier">[[dispatch (enum status, enum impl_state)]] // Explicitly descri=
be what to check</font></div><div><font face=3D"Courier">if ( var =3D=3D st=
atus::foo ) {</font></div><div><font face=3D"Courier">} else if ( var =3D=
=3D impl_state::in_process ) {</font></div><div><span style=3D"font-fa=
mily: Courier;">} // Diagnose missing enumerators from multiple enumeration=
s.</span></div></div><div><font face=3D"Courier"><br></font></div><div><div=
>If we’re hellbent on saving keystrokes (#4), a stronger extension ca=
n do that, still easier and more productive than neutering <font face=3D"Co=
urier">switch</font>. Introduce the case-else statement, which can only app=
ear in the else clause of an if-else statement whose condition is a binary =
expression with a constant expression on one side, or the else clause of an=
other case-else statement. The case statement simply replaces the constant =
expression part of its parent <font face=3D"Courier">if</font>.</div></div>=
<div><br></div><div><div><font face=3D"Courier">if ( num < 0.5 ) {</font=
></div><div><font face=3D"Courier">} else case ( 1.3 ) { // OK, like "else =
if ( num < 1.3 )"</font></div><div><span style=3D"font-family: Courier;"=
>} else case ( 0.8 ) { // optional diagnosis</span></div><div><font face=3D=
"Courier">}</font></div><div><font face=3D"Courier"><br></font></div><div><=
font face=3D"Courier">enum class flags {</font></div><div><font face=3D"Cou=
rier"> zip =3D 1,</font></div><div><font face=3D"Courier">&nbs=
p; buzz =3D 3,</font></div><div><font face=3D"Courier"> =
zap =3D 5</font></div><div><font face=3D"Courier">};</font></div><div><fon=
t face=3D"Courier"><br></font></div><div><font face=3D"Courier">if ( bits &=
amp; flags::zip ) {</font></div><div><font face=3D"Courier">} else case ( f=
lags::buzz ) { // OK, condition is ( bits & flags::buzz )</font></div><=
div><font face=3D"Courier">} // optional diagnosis: bit-value 4 not covered=
</font></div><div><br></div></div><div>I’m not very serious about the=
se proposals, but they’re more than strawmen. So what’s the poi=
nt?</div><div><br></div><div>1. An extension should pick a starting point c=
lose to the finish line. If-else already has the semantics we want, but swi=
tch is how most existing dispatcher code is written. This is a dilemma, but=
think about the balance. Is it so essential to reduce the opt-in barrier t=
o a single keyword, that other applications should be ignored, which are ex=
posed by the things if-else already does?</div><div><br></div><div>2. Erasi=
ng <font face=3D"Courier">break</font> statements (remember, they’re =
just like <font face=3D"Courier">goto</font>s) and adding braces as part of=
the opt-in process are a tangible simplification. It nicely normalizes the=
code and eliminates the need to teach the weirdness of switch, along with =
usage of switch itself. That’s the exact opposite of horrible.</div><=
div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_23178F56-5992-443B-B4B0-DC405C92211A--
.
Author: Myriachan <myriachan@gmail.com>
Date: Sat, 2 Aug 2014 23:24:17 -0700 (PDT)
Raw View
------=_Part_2281_1082263783.1407047057162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Saturday, August 2, 2014 11:55:53 AM UTC-7, Jim Porter wrote:
>
> On 8/2/2014 11:19 AM, Douglas Boffey wrote:=20
> > Regarding labelled breaks, this is something I miss in the language=E2=
=80=94I=20
> > quite often have to write code that needs to break out of an outer loop=
=20
> > after a successful search, and any method I can currently envisage to d=
o=20
> > this are horrible hacks!!!=20
>
> It's not clear to me how a goto constitutes a "horrible hack" in this=20
> case. break and continue are just gotos with an implicit label anyway.=20
> If you go through the effort to label your controls structures so you=20
> can use named break/continue, you really haven't gained much from just=20
> using a goto.=20
>
> About the only benefits I can see are 1) the label goes in a slightly=20
> more obvious place, and 2) the compiler could emit some possibly-useful=
=20
> diagnostics (e.g. to make sure you don't goto a label that's part of an=
=20
> unrelated loop).=20
>
> While I don't actively opposed labeled break/continue, the benefits=20
> don't outweigh the costs of implementation in my opinion. (Also, if this=
=20
> *were* standardized, I'd much rather see it standardized in C first, and=
=20
> then have C++ follow along.)=20
>
There are two reasons in which I can see immediately that labeled break/
continue are useful beyond goto:
1. "Continuing" an outer loop is a pain to do with goto, because you have=
=20
to double-brace your loop in many or most cases:
for (...; ...; ...)
{
do
{
if (r =3D=3D 8)
goto end_of_outer_loop; // error: jumps over initialization of =
"
x"
...
} while (...);
...
class_with_constructor x;
...
end_of_outer_loop: ;
}
2. In C++14/C++1y, a constexpr function cannot contain goto, but *can*=20
contain break and continue. This to me is worth it *right there*. Had I=
=20
known this, I would've mentioned this in my original email.
Labeled break and continue seem like they would avoid the nasty situations=
=20
that goto allows that got goto banned from C++14 constexpr, just like=20
unlabeled break and continue. They don't add anything more complicated in=
=20
the constexpr regard than their unlabeled sisters.
Once I read above in the early replies that this had already been voted on=
=20
alone, I thought it was fine to give up, since really, it wasn't wanted. =
=20
Only in light of the constexpr situation do I think it's worth=20
reconsidering. If that was already considered, or is dismissed easily,=20
then there's not really anything to discuss, and this should just be=20
dropped. It's not worth wasting time since it clearly wasn't a wanted=20
feature at the working group level.
Melissa
--=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_2281_1082263783.1407047057162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, August 2, 2014 11:55:53 AM UTC-7, Jim Porter =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 8/2/2014 11:19 AM, Do=
uglas Boffey wrote:
<br>> Regarding labelled breaks, this is something I miss in the languag=
e=E2=80=94I
<br>> quite often have to write code that needs to break out of an outer=
loop
<br>> after a successful search, and any method I can currently envisage=
to do
<br>> this are horrible hacks!!!
<br>
<br>It's not clear to me how a goto constitutes a "horrible hack" in this=
=20
<br>case. break and continue are just gotos with an implicit label anyway.=
=20
<br>If you go through the effort to label your controls structures so you=
=20
<br>can use named break/continue, you really haven't gained much from just=
=20
<br>using a goto.
<br>
<br>About the only benefits I can see are 1) the label goes in a slightly=
=20
<br>more obvious place, and 2) the compiler could emit some possibly-useful=
=20
<br>diagnostics (e.g. to make sure you don't goto a label that's part of an=
=20
<br>unrelated loop).
<br>
<br>While I don't actively opposed labeled break/continue, the benefits=20
<br>don't outweigh the costs of implementation in my opinion. (Also, if thi=
s=20
<br>*were* standardized, I'd much rather see it standardized in C first, an=
d=20
<br>then have C++ follow along.)
<br></blockquote><div><br>There are two reasons in which I can see immediat=
ely that labeled <span style=3D"font-family: courier new,monospace;">break<=
/span>/<span style=3D"font-family: courier new,monospace;">continue</span> =
are useful beyond <span style=3D"font-family: courier new,monospace;">goto:=
<br></span><br>1. "Continuing" an outer loop is a pain to do with <span sty=
le=3D"font-family: courier new,monospace;">goto</span>, because you have to=
double-brace your loop in many or most cases:<br><br><span style=3D"font-f=
amily: courier new,monospace;">for (<span style=3D"font-family: arial,sans-=
serif;">...</span>; <span style=3D"font-family: arial,sans-serif;">...</spa=
n>; <span style=3D"font-family: arial,sans-serif;">...</span>)<br>{<br>&nbs=
p; do<br> {<br> &nbs=
p; if (r =3D=3D 8)<br> g=
oto end_of_outer_loop; // <span style=3D"font-family: arial,sans-serif;">er=
ror: jumps over initialization of "<span style=3D"font-family: courier new,=
monospace;">x</span>"<br></span> =
<span style=3D"font-family: arial,sans-serif;">...</span><br> &n=
bsp; } while (<span style=3D"font-family: arial,sans-serif;">...</span>);<b=
r> <span style=3D"font-family: arial,sans-serif;">...</sp=
an><br> class_with_constructor x;<br> <=
span style=3D"font-family: arial,sans-serif;">...</span><br>end_of_outer_lo=
op: ;<br>}<br></span><br>2. In C++14/C++1y, a <span style=3D"font-family: c=
ourier new,monospace;">constexpr</span> function cannot contain <span style=
=3D"font-family: courier new,monospace;">goto</span>, but <i>can</i> contai=
n <span style=3D"font-family: courier new,monospace;">break</span> and <spa=
n style=3D"font-family: courier new,monospace;">continue</span>. This=
to me is worth it <i>right there</i>. Had I known this, I would've m=
entioned this in my original email.<br><br>Labeled <span style=3D"font-fami=
ly: courier new,monospace;">break</span> and <span style=3D"font-family: co=
urier new,monospace;">continue</span> seem like they would avoid the nasty =
situations that <span style=3D"font-family: courier new,monospace;">goto</s=
pan> allows that got <span style=3D"font-family: courier new,monospace;">go=
to</span> banned from C++14 <span style=3D"font-family: courier new,monospa=
ce;">constexpr</span>, just like unlabeled <span style=3D"font-family: cour=
ier new,monospace;">break</span> and <span style=3D"font-family: courier ne=
w,monospace;">continue</span>. They don't add anything more complicat=
ed in the <span style=3D"font-family: courier new,monospace;">constexpr</sp=
an> regard than their unlabeled sisters.<br><br>Once I read above in the ea=
rly replies that this had already been voted on alone, I thought it was fin=
e to give up, since really, it wasn't wanted. Only in light of the <s=
pan style=3D"font-family: courier new,monospace;">constexpr</span> situatio=
n do I think it's worth reconsidering. If that was already considered=
, or is dismissed easily, then there's not really anything to discuss, and =
this should just be dropped. It's not worth wasting time since it cle=
arly wasn't a wanted feature at the working group level.<br><br>Melissa<br>=
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2281_1082263783.1407047057162--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 01:31:33 -0700 (PDT)
Raw View
------=_Part_1690_1838773293.1407054693719
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi
On Sunday, August 3, 2014 6:24:17 PM UTC+12, Myriachan wrote:
>
> On Saturday, August 2, 2014 11:55:53 AM UTC-7, Jim Porter wrote:
>>
>> On 8/2/2014 11:19 AM, Douglas Boffey wrote:=20
>> > Regarding labelled breaks, this is something I miss in the language=E2=
=80=94I=20
>> > quite often have to write code that needs to break out of an outer loo=
p=20
>> > after a successful search, and any method I can currently envisage to=
=20
>> do=20
>> > this are horrible hacks!!!=20
>>
>> It's not clear to me how a goto constitutes a "horrible hack" in this=20
>> case. break and continue are just gotos with an implicit label anyway.=
=20
>> If you go through the effort to label your controls structures so you=20
>> can use named break/continue, you really haven't gained much from just=
=20
>> using a goto.=20
>>
>> About the only benefits I can see are 1) the label goes in a slightly=20
>> more obvious place, and 2) the compiler could emit some possibly-useful=
=20
>> diagnostics (e.g. to make sure you don't goto a label that's part of an=
=20
>> unrelated loop).=20
>>
>> While I don't actively opposed labeled break/continue, the benefits=20
>> don't outweigh the costs of implementation in my opinion. (Also, if this=
=20
>> *were* standardized, I'd much rather see it standardized in C first, and=
=20
>> then have C++ follow along.)=20
>>
>
> There are two reasons in which I can see immediately that labeled break/
> continue are useful beyond goto:
>
> 1. "Continuing" an outer loop is a pain to do with goto, because you have=
=20
> to double-brace your loop in many or most cases:
>
> for (...; ...; ...)
> {
> do
> {
> if (r =3D=3D 8)
> goto end_of_outer_loop; // error: jumps over initialization=
=20
> of "x"
> ...
> } while (...);
> ...
> class_with_constructor x;
> ...
> end_of_outer_loop: ;
> }
>
> 2. In C++14/C++1y, a constexpr function cannot contain goto, but *can*=20
> contain break and continue. This to me is worth it *right there*. Had I=
=20
> known this, I would've mentioned this in my original email.
>
> Labeled break and continue seem like they would avoid the nasty=20
> situations that goto allows that got goto banned from C++14 constexpr,=20
> just like unlabeled break and continue. They don't add anything more=20
> complicated in the constexpr regard than their unlabeled sisters.
>
> Once I read above in the early replies that this had already been voted o=
n=20
> alone, I thought it was fine to give up, since really, it wasn't wanted. =
=20
> Only in light of the constexpr situation do I think it's worth=20
> reconsidering. If that was already considered, or is dismissed easily,=
=20
> then there's not really anything to discuss, and this should just be=20
> dropped. It's not worth wasting time since it clearly wasn't a wanted=20
> feature at the working group level.
>
> Melissa
>
I've no doubt the feature is useful when you want it, I just doubt the need=
=20
comes up that often. I can't recall the last time I wanted to do this. It=
=20
happens, but is so infrequent, at least for me.
I think the best thing someone can do to promote this feature is get some=
=20
kind of estimate about how often the feature is actually used in Java, to=
=20
determine if it's really worth adding to C++. Don't you think?
And if it does get added, does it have to look like:
x: for (...)
{
continue x;
}
Or is there interest for something like:
for named x (...)
{
}
which I'm inclined to like more because there's less of a feeling that=20
continue x is going to goto the initializer part.
I'd also like to see the name only exist inside the inner loop scopes. It=
=20
wasn't clear to me if that was part of other proposals, it looked to me=20
like it wasn't.
and why not (apart from the new keyword.
switch named x (I)
{
switch named y (I)
{
case 1: break x;
}
}
Presumably the idea is also to include do named x() { }, while named x() {=
=20
}
If people need to feel better about not using goto's presumably why stop at=
=20
for and why not include switch.
And what about (just to be crazy):
for named x ()
{
switch named y (x)
{
case 1:
continue y; re-switch?
case 2:
break x;
}
}
I'm pretty sure all these ideas have come up before though but will=20
probably all continue to not get traction unless theirs some stats that=20
show it's really used in java etc. in any significant way. I'm having a=20
hard time believing it is used a lot, but I have no proof, only my own=20
experience to go on and that would appear to differ from other peoples. But=
=20
if we knew the Java stats I think it would reveal more of a real truth.
--=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_1690_1838773293.1407054693719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Sunday, August 3, 2014 6:24:17 PM UTC+12, Myr=
iachan 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-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Saturday, Aug=
ust 2, 2014 11:55:53 AM UTC-7, Jim Porter wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
">On 8/2/2014 11:19 AM, Douglas Boffey wrote:
<br>> Regarding labelled breaks, this is something I miss in the languag=
e=E2=80=94I
<br>> quite often have to write code that needs to break out of an outer=
loop
<br>> after a successful search, and any method I can currently envisage=
to do
<br>> this are horrible hacks!!!
<br>
<br>It's not clear to me how a goto constitutes a "horrible hack" in this=
=20
<br>case. break and continue are just gotos with an implicit label anyway.=
=20
<br>If you go through the effort to label your controls structures so you=
=20
<br>can use named break/continue, you really haven't gained much from just=
=20
<br>using a goto.
<br>
<br>About the only benefits I can see are 1) the label goes in a slightly=
=20
<br>more obvious place, and 2) the compiler could emit some possibly-useful=
=20
<br>diagnostics (e.g. to make sure you don't goto a label that's part of an=
=20
<br>unrelated loop).
<br>
<br>While I don't actively opposed labeled break/continue, the benefits=20
<br>don't outweigh the costs of implementation in my opinion. (Also, if thi=
s=20
<br>*were* standardized, I'd much rather see it standardized in C first, an=
d=20
<br>then have C++ follow along.)
<br></blockquote><div><br>There are two reasons in which I can see immediat=
ely that labeled <span style=3D"font-family: courier new,monospace;">break<=
/span>/<span style=3D"font-family: courier new,monospace;">continue</span> =
are useful beyond <span style=3D"font-family: courier new,monospace;">goto:=
<br></span><br>1. "Continuing" an outer loop is a pain to do with <span sty=
le=3D"font-family: courier new,monospace;">goto</span>, because you have to=
double-brace your loop in many or most cases:<br><br><span style=3D"font-f=
amily: courier new,monospace;">for (<span style=3D"font-family: arial,sans-=
serif;">...</span>; <span style=3D"font-family: arial,sans-serif;">...</spa=
n>; <span style=3D"font-family: arial,sans-serif;">...</span>)<br>{<br>&nbs=
p; do<br> {<br> &nbs=
p; if (r =3D=3D 8)<br> g=
oto end_of_outer_loop; // <span style=3D"font-family: arial,sans-serif;">er=
ror: jumps over initialization of "<span style=3D"font-family: courier new,=
monospace;">x</span>"<br></span> =
<span style=3D"font-family: arial,sans-serif;">...</span><br> &n=
bsp; } while (<span style=3D"font-family: arial,sans-serif;">...</span>);<b=
r> <span style=3D"font-family: arial,sans-serif;">...</sp=
an><br> class_with_constructor x;<br> <=
span style=3D"font-family: arial,sans-serif;">...</span><br>end_of_outer_lo=
op: ;<br>}<br></span><br>2. In C++14/C++1y, a <span style=3D"font-family: c=
ourier new,monospace;">constexpr</span> function cannot contain <span style=
=3D"font-family: courier new,monospace;">goto</span>, but <i>can</i> contai=
n <span style=3D"font-family: courier new,monospace;">break</span> and <spa=
n style=3D"font-family: courier new,monospace;">continue</span>. This=
to me is worth it <i>right there</i>. Had I known this, I would've m=
entioned this in my original email.<br><br>Labeled <span style=3D"font-fami=
ly: courier new,monospace;">break</span> and <span style=3D"font-family: co=
urier new,monospace;">continue</span> seem like they would avoid the nasty =
situations that <span style=3D"font-family: courier new,monospace;">goto</s=
pan> allows that got <span style=3D"font-family: courier new,monospace;">go=
to</span> banned from C++14 <span style=3D"font-family: courier new,monospa=
ce;">constexpr</span>, just like unlabeled <span style=3D"font-family: cour=
ier new,monospace;">break</span> and <span style=3D"font-family: courier ne=
w,monospace;">continue</span>. They don't add anything more complicat=
ed in the <span style=3D"font-family: courier new,monospace;">constexpr</sp=
an> regard than their unlabeled sisters.<br><br>Once I read above in the ea=
rly replies that this had already been voted on alone, I thought it was fin=
e to give up, since really, it wasn't wanted. Only in light of the <s=
pan style=3D"font-family: courier new,monospace;">constexpr</span> situatio=
n do I think it's worth reconsidering. If that was already considered=
, or is dismissed easily, then there's not really anything to discuss, and =
this should just be dropped. It's not worth wasting time since it cle=
arly wasn't a wanted feature at the working group level.<br><br>Melissa<br>=
</div></div></blockquote><div><br></div><div>I've no doubt the feature is u=
seful when you want it, I just doubt the need comes up that often. I can't =
recall the last time I wanted to do this. It happens, but is so infrequent,=
at least for me.</div><div><br></div><div>I think the best thing someone c=
an do to promote this feature is get some kind of estimate about how o=
ften the feature is actually used in Java, to determine if it's really wort=
h adding to C++. Don't you think?</div><div><br></div><div>And if it does g=
et added, does it have to look like:</div><div><br></div><div>x: =
for (...)<br>{</div><div>continue x;<br>}</div><div><br></div><div>Or is th=
ere interest for something like:</div><div>for named x (...)<br>{<br>}</div=
><div><br></div><div>which I'm inclined to like more because there's less o=
f a feeling that continue x is going to goto the initializer part.</div><di=
v>I'd also like to see the name only exist inside the inner loop scope=
s. It wasn't clear to me if that was part of other proposals, it looked to =
me like it wasn't.</div><div><br></div><div>and why not (apart from the new=
keyword.</div><div>switch named x (I)</div><div>{</div><div>switch named y=
(I)</div><div>{</div><div> case 1: break x;<br>}<br>}</div><di=
v><br></div><div>Presumably the idea is also to include do named x() =
{ }, while named x() { }</div><div><br></div><div>If people need to feel be=
tter about not using goto's presumably why stop at for and why not inc=
lude switch.</div><div><br></div><div>And what about (just to be crazy):</d=
iv><div>for named x ()</div><div>{</div><div>switch named y (x)</div><div>{=
</div><div>case 1:</div><div>continue y; re-switch?</div><div>case 2:<=
/div><div> break x;<br>}<br>}</div><div><br></div><div>I'=
m pretty sure all these ideas have come up before though but will probably =
all continue to not get traction unless theirs some stats that show it's re=
ally used in java etc. in any significant way. I'm having a hard time belie=
ving it is used a lot, but I have no proof, only my own experience to go on=
and that would appear to differ from other peoples. But if we knew the Jav=
a stats I think it would reveal more of a real truth.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1690_1838773293.1407054693719--
.
Author: Myriachan <myriachan@gmail.com>
Date: Sun, 3 Aug 2014 14:18:38 -0700 (PDT)
Raw View
Hi... I'm on a device that can't easily properly quote, sorry.
> I've no doubt the feature is useful when you
> want it, I just doubt the need comes up that
> often. I can't recall the last time I wanted to do
> this. It happens, but is so infrequent, at least
> for me.
It comes up a lot for me, primary in the form of parsing strings:
void ExecuteCommand(const char *cmd, std::ptrdiff_t cmdLength);
....
const char *cmdStart = string;
for (const char *p = string; ; ++p)
{
switch (char ch = *i)
{
case '\0':
goto end;
case ',':
break;
default:
continue;
}
ExecuteCommand(cmdStart, p - cmdStart);
cmdStart = p + 1;
}
end:
....
In the above, the "goto end" would become a "break outer".
> I think the best thing someone can do to
> promote this feature is get some kind of
> estimate about how often the feature is actually
> used in Java, to determine if it's really worth
> adding to C++. Don't you think?
Sure, that might be useful information, but my point about C++14 relaxed constexpr still stands: you can't use goto.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Thomas Braxton <kde.braxton@gmail.com>
Date: Sun, 3 Aug 2014 14:29:46 -0700 (PDT)
Raw View
------=_Part_1119_1435250867.1407101386421
Content-Type: text/plain; charset=UTF-8
On Sunday, August 3, 2014 4:18:39 PM UTC-5, Myriachan wrote:
>
> Hi... I'm on a device that can't easily properly quote, sorry.
>
> > I've no doubt the feature is useful when you
> > want it, I just doubt the need comes up that
> > often. I can't recall the last time I wanted to do
> > this. It happens, but is so infrequent, at least
> > for me.
>
> It comes up a lot for me, primary in the form of parsing strings:
>
> void ExecuteCommand(const char *cmd, std::ptrdiff_t cmdLength);
> ...
> const char *cmdStart = string;
> for (const char *p = string; ; ++p)
> {
>
Couldn't this be written as:
for (const char *p = string; *p; ++p) ?
Then you wouldn't need to check for NUL inside the 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_1119_1435250867.1407101386421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, August 3, 2014 4:18:39 PM UTC-5, Myriachan wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">Hi... I'm on a device =
that can't easily properly quote, sorry.<p>> I've no doubt the feature i=
s useful when you<br>> want it, I just doubt the need comes up that<br>&=
gt; often. I can't recall the last time I wanted to do<br>> this. It hap=
pens, but is so infrequent, at least<br>> for me.</p><p>It comes up a lo=
t for me, primary in the form of parsing strings:</p><p>void ExecuteCommand=
(const char *cmd, std::ptrdiff_t cmdLength);<br>...<br>const char *cmdStart=
=3D string;<br>for (const char *p =3D string; ; ++p)<br>{<br></p></blockqu=
ote><div>Couldn't this be written as:<br>for (const char *p =3D string; *p;=
++p) ?</div><div>Then you wouldn't need to check for NUL inside the switch=
.. </div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p=
></p><p></p><p></p><p></p><p></p><p></p></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1119_1435250867.1407101386421--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 17:09:41 -0700 (PDT)
Raw View
------=_Part_2781_805448145.1407110981836
Content-Type: text/plain; charset=UTF-8
Hi
On Monday, August 4, 2014 9:29:46 AM UTC+12, Thomas Braxton wrote:
>
> On Sunday, August 3, 2014 4:18:39 PM UTC-5, Myriachan wrote:
>>
>> Hi... I'm on a device that can't easily properly quote, sorry.
>>
>> > I've no doubt the feature is useful when you
>> > want it, I just doubt the need comes up that
>> > often. I can't recall the last time I wanted to do
>> > this. It happens, but is so infrequent, at least
>> > for me.
>>
>> It comes up a lot for me, primary in the form of parsing strings:
>>
>> void ExecuteCommand(const char *cmd, std::ptrdiff_t cmdLength);
>> ...
>> const char *cmdStart = string;
>> for (const char *p = string; ; ++p)
>> {
>>
> Couldn't this be written as:
> for (const char *p = string; *p; ++p) ?
> Then you wouldn't need to check for NUL inside the switch.
>
>
I think the point is that it could be any character,
I don't know if another example is any more obvious, but I'll try:
std::string get_file_extension( const std::string& path )
{
for (size_t i = path.length(); i > 0;)
{
--i;
switch (path[i])
{
case '\\':
case '/':
goto the_end;
case '.':
{ // Grrr, hate braces.
std::wstring ext = path.substr(i+1);
return ext;
}
}
}
the_end:
return std::wstring();
}
// C++2030/never.
std::string get_file_extension( const std::string& path )
{
for named with_difficulty (size_t i = path.length(); i > 0;)
{
--i;
explicit switch (path[i])
{
case '\\':
case '/':
// Can imagine name clashes on adding new loops,
// naming is hard/boring, lots of x, y, z, loop1, loop2
etc.
break with_difficulty;
case '.': // Legal in another sadly rejected proposal, right?
std::wstring ext = path.substr(i+1);
return ext;
}
}
return std::wstring();
}
The constexpr / goto argument seems somewhat compelling but maybe there are
other work arounds.
(Would like to know the latest thinking on constexpr proliferation actually
and making it mean must be constexpr etc.)
I guess if I don't think I need the feature enough to warrant adding it, I
can't be also get too worried about people using the feature to introduce
bad code, because by definition that wouldn't be too often either... and
if it helps constexpr functions by adding it, then maybe. Interesting what
other people have to say on it but still wish we had estimates of java use
/ abuse. Anyone from google here know how you estimate that kind of 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_2781_805448145.1407110981836
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Monday, August 4, 2014 9:29:46 AM UTC+12, Tho=
mas Braxton wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bord=
er-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr">On Sunday, =
August 3, 2014 4:18:39 PM UTC-5, Myriachan 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=
;">Hi... I'm on a device that can't easily properly quote, sorry.<p>&=
gt; I've no doubt the feature is useful when you<br>> want it, I just do=
ubt the need comes up that<br>> often. I can't recall the last time I wa=
nted to do<br>> this. It happens, but is so infrequent, at least<br>>=
for me.</p><p>It comes up a lot for me, primary in the form of parsing str=
ings:</p><p>void ExecuteCommand(const char *cmd, std::ptrdiff_t cmdLength);=
<br>...<br>const char *cmdStart =3D string;<br>for (const char *p =3D strin=
g; ; ++p)<br>{<br></p></blockquote><div>Couldn't this be written as:<br>for=
(const char *p =3D string; *p; ++p) ?</div><div>Then you wouldn't need to =
check for NUL inside the switch. </div><div><br></div></div></blockquo=
te><div><br></div><div>I think the point is that it could be any chara=
cter,</div><div>I don't know if another example is any more obvious, b=
ut I'll try:</div><div><br></div><div>std::string get_file_extension( const=
std::string& path )<br>{<br> for (size_t i =3D path.=
length(); i > 0;)<br> {<br> &nb=
sp; --i;<br> switch (=
path[i])<br> {<br> &nb=
sp; case '\\':<br> &nb=
sp; case '/':<br>&nbs=
p; &=
nbsp; goto the_end;<br> &nbs=
p; case '.': </div><div> &nb=
sp; { // Grrr, hate braces.<br>&n=
bsp;  =
; std::wstring ext =3D path.substr(i+1);<br> &=
nbsp; ret=
urn ext;<br> &nb=
sp; }<br> }<br> =
}<br>the_end:<br> return std::wstring();<br>}<br></div><=
div><br></div><div>// C++2030/never.</div><div><br></div><div><div>std::str=
ing get_file_extension( const std::string& path )<br>{<br> &=
nbsp; for named with_difficulty (size_t i =3D path.length(); i > 0;=
)<br> {<br> --i=
;<br> explicit switch (path[i])<b=
r> {<br> &=
nbsp; case '\\':<br> &=
nbsp; case '/':</div><div> &=
nbsp; &nbs=
p; // Can imagine name clashes on adding new loops,</=
div><div> =
// naming is hard/boring, lots of x, y, z, l=
oop1, loop2 etc.<br> &=
nbsp; break with_difficulty;</div><div>&=
nbsp; case '.':=
// Legal in another sadly rejected proposal, right?</div><=
div>  =
; std::wstring ext =3D path.substr(i+1);<br> &=
nbsp; &nbs=
p; return ext;<br> }<br> &nb=
sp; }<br> return std::wstring();<br>}</div><div><br=
></div><div>The constexpr / goto argument seems somewhat compelling bu=
t maybe there are other work arounds.</div><div>(Would like to know the lat=
est thinking on constexpr proliferation actually and making it mean must be=
constexpr etc.)</div><div><br></div><div>I guess if I don't think I need t=
he feature enough to warrant adding it, I can't be also get too worried abo=
ut people using the feature to introduce bad code, because by definit=
ion that wouldn't be too often either... and if it helps constexpr function=
s by adding it, then maybe. Interesting what other people have to say on it=
but still wish we had estimates of java use / abuse. Anyone from google he=
re know how you estimate that kind of stuff?<br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2781_805448145.1407110981836--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 4 Aug 2014 08:56:01 +0800
Raw View
--Apple-Mail=_A337D284-9BA2-4E36-BCBB-C700FED33A53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-04, at 8:09 AM, gmisocpp@gmail.com wrote:
> I think the point is that it could be any character,
I think the point is that parsers have more complicated control flow than a=
verage.
Arguments based on "you could do without" miss the point. We could do witho=
ut a lot of things, but less complicated constructs do not necessarily lead=
to less complicated code. If you need to think about how to do without som=
ething, the code is probably more complex without.
Variables that disambiguate multiple, completely different reasons for bein=
g at a particular line of code are a headache and a source of errors. Every=
line should have clear invariants. I'd take a goto any day, over trying to=
loosen conditions for every line between points A and B. And a clean break=
statement, that's a no-brainer.
The invariants at the target label do need to be met at the goto, but that'=
s just what goto expresses. Other styles usually fail to emphasize this, or=
relegate to a comment where a flag ultimately transfers control to, or whe=
ther the flag has (intentional) side-effects along the way. The same applie=
s to break/continue, except with even more obvious meaning. Quite often a "=
finished" flag fails to stop some normal processing from unintentionally ha=
ppening. Setting a flag is a decision to run part of the loop with the vari=
ables now past the end.
> The constexpr / goto argument seems somewhat compelling but maybe there a=
re other work arounds.
I do not see what's so special about goto. C++ defines whether and how you =
can jump from one point to another. The analysis is the same at constexpr t=
ime as it is at runtime, and it's not even a special case if other branch s=
tatements handle scope transfer generically -- which is probably a great de=
sign choice anyway.
> (Would like to know the latest thinking on constexpr proliferation actual=
ly and making it mean must be constexpr etc.)
So far (as I'm aware) only Clang has relaxed constexpr and I recall someone=
saying that goto wouldn't have been a problem. (Richard?)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A337D284-9BA2-4E36-BCBB-C700FED33A53
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–04, at 8:09 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; =
font-style: normal; font-variant: normal; font-weight: normal; letter-spaci=
ng: normal; line-height: normal; orphans: auto; text-align: start; text-ind=
ent: 0px; text-transform: none; white-space: normal; widows: auto; word-spa=
cing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>I think t=
he point is that it could be any character,</div></div></div></blockqu=
ote><div><br></div><div>I think the point is that parsers have more complic=
ated control flow than average.</div><div><br></div><div>Arguments based on=
“you could do without” miss the point. We could do without a l=
ot of things, but less complicated constructs do not necessarily lead to le=
ss complicated code. If you need to think about how to do without something=
, the code is probably more complex without.</div><div><br></div><div>Varia=
bles that disambiguate multiple, completely different reasons for being at =
a particular line of code are a headache and a source of errors. Every line=
should have clear invariants. I’d take a goto any day, over trying t=
o loosen conditions for every line between points A and B. And a clean <fon=
t face=3D"Courier">break</font> statement, that’s a no-brainer.</div>=
<div><br></div><div>The invariants at the target label do need to be met at=
the goto, but that’s just what goto expresses. Other styles usually =
fail to emphasize this, or relegate to a comment where a flag ultimately tr=
ansfers control to, or whether the flag has (intentional) side-effects alon=
g the way. The same applies to break/continue, except with even more obviou=
s meaning. Quite often a “finished” flag fails to stop some nor=
mal processing from unintentionally happening. Setting a flag is a decision=
to run part of the loop with the variables now past the end.</div><div><br=
></div><blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font=
-size: 12px; font-style: normal; font-variant: normal; font-weight: normal;=
letter-spacing: normal; line-height: normal; orphans: auto; text-align: st=
art; text-indent: 0px; text-transform: none; white-space: normal; widows: a=
uto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><=
div><div>The constexpr / goto argument seems somewhat compelling but m=
aybe there are other work arounds.</div></div></div></div></blockquote><div=
><br></div><div>I do not see what’s so special about goto. C++ define=
s whether and how you can jump from one point to another. The analysis is t=
he same at constexpr time as it is at runtime, and it’s not even a sp=
ecial case if other branch statements handle scope transfer generically &md=
ash; which is probably a great design choice anyway.</div><br><blockquote t=
ype=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px; font-st=
yle: normal; font-variant: normal; font-weight: normal; letter-spacing: nor=
mal; line-height: normal; orphans: auto; text-align: start; text-indent: 0p=
x; text-transform: none; white-space: normal; widows: auto; word-spacing: 0=
px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div><div>(Would like=
to know the latest thinking on constexpr proliferation actually and making=
it mean must be constexpr etc.)</div></div></div></div></blockquote><div><=
br></div><div>So far (as I’m aware) only Clang has relaxed constexpr =
and I recall someone saying that goto wouldn’t have been a problem. (=
Richard?)</div></div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A337D284-9BA2-4E36-BCBB-C700FED33A53--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 18:39:08 -0700 (PDT)
Raw View
------=_Part_2407_1598443438.1407116348534
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, August 4, 2014 12:56:04 PM UTC+12, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9304, at 8:09 AM, gmis...@gmail.com <javascript:=
> wrote:
>
> I think the point is that it could be any character,
>
>
> I think the point is that parsers have more complicated control flow than=
=20
> average.
>
I agree, I meant it could be anything, or any loop, the issue of characters=
=20
wasn't important.=20
>
> Arguments based on =E2=80=9Cyou could do without=E2=80=9D miss the point.=
We could do=20
> without a lot of things, but less complicated constructs do not necessari=
ly=20
> lead to less complicated code. If you need to think about how to do witho=
ut=20
> something, the code is probably more complex without.
>
I strongly disagree here. You have to have some metrics for adding features=
=20
or you add everything.=20
"I would barely use this feature" is my starting proposition on this=20
feature, and it's exactly a reasonable and right metric to begin to apply=
=20
here. it definitely doesn't miss the point.
If we add the feature and we later find it has as many issues as it solves,=
=20
we haven't really gone anywhere other than complicating the language.
For instance, in my previous example I wondered if we would name lots of=20
loops a/b/c and then make mistakes on which one we were referring to. It=20
might not be major concern but it's stuff to consider.
That I feel I would barely use the proposed feature doesn't mean anything=
=20
at this stage though, it's my initial suggestion not a definitive statement=
=20
and it's a reasonable starting proposition that needs to be tested. If=20
people demonstrate that I could do more with the feature that I can=20
currently can imagine, I'd change my tune on my mild opposition to the=20
feature. The goto/constexpr argument seemed an interesting one in that=20
direction but it just depends what the balance turns out to be. But without=
=20
challenging it's usefulness with some metric, people won't come forward=20
with their best arguments on for and against to really be able to tell the=
=20
true value of something.
> Variables that disambiguate multiple, completely different reasons for=20
> being at a particular line of code are a headache and a source of errors.=
=20
> Every line should have clear invariants. I=E2=80=99d take a goto any day,=
over=20
> trying to loosen conditions for every line between points A and B. And a=
=20
> clean break statement, that=E2=80=99s a no-brainer.
>
> The invariants at the target label do need to be met at the goto, but=20
> that=E2=80=99s just what goto expresses. Other styles usually fail to emp=
hasize=20
> this, or relegate to a comment where a flag ultimately transfers control=
=20
> to, or whether the flag has (intentional) side-effects along the way. The=
=20
> same applies to break/continue, except with even more obvious meaning.=20
> Quite often a =E2=80=9Cfinished=E2=80=9D flag fails to stop some normal p=
rocessing from=20
> unintentionally happening. Setting a flag is a decision to run part of th=
e=20
> loop with the variables now past the end.
>
I agree that variables set purely to break out of a loop don't aid=20
readability etc. if that's what you mean. But often I want such a value=20
later anyway which somewhat mitigates that. I don't like complex code for=
=20
processing something that's found in a loop, stuck doing that processing=20
way nested in the loop(s). But I often need the flag out of the loop to=20
decide if I should do that process when I get there as well as to exit.=20
This seems to somewhat mitigate the redundancy I'm inferring from your=20
argument of, in many cases.
> The constexpr / goto argument seems somewhat compelling but maybe there=
=20
> are other work arounds.
>
>
> I do not see what=E2=80=99s so special about goto. C++ defines whether an=
d how you=20
> can jump from one point to another. The analysis is the same at constexpr=
=20
> time as it is at runtime, and it=E2=80=99s not even a special case if oth=
er branch=20
> statements handle scope transfer generically =E2=80=94 which is probably =
a great=20
> design choice anyway.
>
> (Would like to know the latest thinking on constexpr proliferation=20
> actually and making it mean must be constexpr etc.)
>
>
> So far (as I=E2=80=99m aware) only Clang has relaxed constexpr and I reca=
ll=20
> someone saying that goto wouldn=E2=80=99t have been a problem. (Richard?)
>
>
I think you arguing why can't goto be in constexpr? I'm not sure.
=20
Overall I don't think a break x / continue x feature would be a big issue=
=20
left in or out, I thought a lot about the idea in the past, and maybe even=
=20
suggesting it, but I've since become a lot more indifferent to the feature.=
=20
It doesn't seem a killer feature to me. But it doesn't sound like it would=
=20
incredibly complicate the language either because it seems pretty obvious.
It's good it gets a wider discussion though, I enjoy reading peoples=20
positions on it. I hope the explicit switch type ideas get more discussion=
=20
time too, despite it being rejected. I'd still like a case scope / better=
=20
switch if it were possible. It does seem hard to solve cleanly though and=
=20
will have lots of opposition but it'd be nice if some winning idea came=20
through all of that.
--=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_2407_1598443438.1407116348534
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 4, 2014 12:56:04 PM UTC+12, Davi=
d Krauss wrote:<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-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: br=
eak-word;"><br><div><div>On 2014=E2=80=9308=E2=80=9304, at 8:09 AM, <a onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"rdbO0MURAB8J">gmis...@gmail.com</a> wrote:</div><br><blockq=
uote type=3D"cite"><div style=3D"font: 12px/normal Helvetica; text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white=
-space: normal; font-size-adjust: none; font-stretch: normal;"><div dir=3D"=
ltr"><div>I think the point is that it could be any character,</div></=
div></div></blockquote><div><br></div><div>I think the point is that parser=
s have more complicated control flow than average.</div></div></div></block=
quote><div>I agree, I meant it could be anything, or any loop, the iss=
ue of characters wasn't important. </div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-col=
or: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">=
<div style=3D"-ms-word-wrap: break-word;"><div><div><br></div><div>Argument=
s based on =E2=80=9Cyou could do without=E2=80=9D miss the point. We could =
do without a lot of things, but less complicated constructs do not necessar=
ily lead to less complicated code. If you need to think about how to do wit=
hout something, the code is probably more complex without.</div></div></div=
></blockquote><div><br></div><div>I strongly disagree here. You have to hav=
e some metrics for adding features or you add everything. </=
div><div>"I would barely use this feature" is my starting proposi=
tion on this feature, and it's exactly a reasonable and right met=
ric to begin to apply here. it definitely doesn't miss the point.=
</div><div><br></div><div>If we add the feature and we later find it has as=
many issues as it solves, we haven't really gone anywhere other than compl=
icating the language.</div><div><br></div><div>For instance, in my previous=
example I wondered if we would name lots of loops a/b/c and then make mist=
akes on which one we were referring to. It might not be major concern but i=
t's stuff to consider.</div><div><br></div><div><div>That I feel I would ba=
rely use the proposed feature doesn't mean anything at this stage thou=
gh, it's my initial suggestion not a definitive statement and it'=
s a reasonable starting proposition that needs to be tested. If people=
demonstrate that I could do more with the feature that I can currently can=
imagine, I'd change my tune on my mild opposition to the feature. The goto=
/constexpr argument seemed an interesting one in that direction but it just=
depends what the balance turns out to be. But without challenging it's use=
fulness with some metric, people won't come forward with their best argumen=
ts on for and against to really be able to tell the true value of some=
thing.</div></div><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, 204); border-left-width: 1px; border-left-style: solid;"><div style=3D=
"-ms-word-wrap: break-word;"><div><div><br></div><div>Variables that disamb=
iguate multiple, completely different reasons for being at a particular lin=
e of code are a headache and a source of errors. Every line should have cle=
ar invariants. I=E2=80=99d take a goto any day, over trying to loosen condi=
tions for every line between points A and B. And a clean <font face=3D"Cour=
ier">break</font> statement, that=E2=80=99s a no-brainer.</div></div></div>=
</blockquote><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, =
204); border-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-=
word-wrap: break-word;"><div><div><br></div><div>The invariants at the targ=
et label do need to be met at the goto, but that=E2=80=99s just what goto e=
xpresses. Other styles usually fail to emphasize this, or relegate to a com=
ment where a flag ultimately transfers control to, or whether the flag has =
(intentional) side-effects along the way. The same applies to break/continu=
e, except with even more obvious meaning. Quite often a =E2=80=9Cfinished=
=E2=80=9D flag fails to stop some normal processing from unintentionally ha=
ppening. Setting a flag is a decision to run part of the loop with the vari=
ables now past the end.</div></div></div></blockquote><div><br></div><div><=
div>I agree that variables set purely to break out of a loop don't aid read=
ability etc. if that's what you mean. But often I want such a value la=
ter anyway which somewhat mitigates that. I don't like complex code fo=
r processing something that's found in a loop, stuck doing that processing =
way nested in the loop(s). But I often need the flag out of the loop to dec=
ide if I should do that process when I get there as well as to exit. This s=
eems to somewhat mitigate the redundancy I'm inferring from your argum=
ent of, in many cases.</div><div><br></div></div><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 style=3D"-ms-word-wrap: break-word;"><div><div><br></div><bloc=
kquote type=3D"cite"><div style=3D"font: 12px/normal Helvetica; text-transf=
orm: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; whi=
te-space: normal; font-size-adjust: none; font-stretch: normal;"><div dir=
=3D"ltr"><div><div>The constexpr / goto argument seems somewhat compel=
ling but maybe there are other work arounds.</div></div></div></div></block=
quote><div><br></div><div>I do not see what=E2=80=99s so special about goto=
.. C++ defines whether and how you can jump from one point to another. The a=
nalysis is the same at constexpr time as it is at runtime, and it=E2=80=99s=
not even a special case if other branch statements handle scope transfer g=
enerically =E2=80=94 which is probably a great design choice anyway.</div><=
/div></div></blockquote><div><br></div><blockquote class=3D"gmail_quote" st=
yle=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 st=
yle=3D"-ms-word-wrap: break-word;"><div><br><blockquote type=3D"cite"><div =
style=3D"font: 12px/normal Helvetica; text-transform: none; text-indent: 0p=
x; letter-spacing: normal; word-spacing: 0px; white-space: normal; font-siz=
e-adjust: none; font-stretch: normal;"><div dir=3D"ltr"><div><div>(Would li=
ke to know the latest thinking on constexpr proliferation actually and maki=
ng it mean must be constexpr etc.)</div></div></div></div></blockquote><div=
><br></div><div>So far (as I=E2=80=99m aware) only Clang has relaxed conste=
xpr and I recall someone saying that goto wouldn=E2=80=99t have been a prob=
lem. (Richard?)</div></div><br></div></blockquote><div><br></div><div><div>=
I think you arguing why can't goto be in constexpr? I'm not sure.</div=
> </div><div>Overall I don't think a break x / continue x feature woul=
d be a big issue left in or out, I thought a lot about the idea in the=
past, and maybe even suggesting it, but I've since become a lot more indif=
ferent to the feature. It doesn't seem a killer feature to me. But it doesn=
't sound like it would incredibly complicate the language either because it=
seems pretty obvious.</div><div><br></div><div>It's good it gets a wider d=
iscussion though, I enjoy reading peoples positions on it. I hope the expli=
cit switch type ideas get more discussion time too, despite it being reject=
ed. I'd still like a case scope / better switch if it were possible. It doe=
s seem hard to solve cleanly though and will have lots of opposition but it=
'd be nice if some winning idea came through all of that.</div><div><br></d=
iv></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2407_1598443438.1407116348534--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 4 Aug 2014 10:08:55 +0800
Raw View
--Apple-Mail=_085288A7-13A4-4776-BED8-40D1315057A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-04, at 9:39 AM, gmisocpp@gmail.com wrote:
> \"I would barely use this feature" is my starting proposition on this fea=
ture, and it's exactly a reasonable and right metric to begin to apply here=
.. it definitely doesn't miss the point.
Do you write parsers? Do you write optimized numeric solvers (which tend to=
also look like parsers)?
You can't apply that metric unless you're God. If someone else says somethi=
ng is useful, it's better to give the benefit of the doubt.
> If we add the feature and we later find it has as many issues as it solve=
s, we haven't really gone anywhere other than complicating the language.
Nobody's suggested any risk. The feature has been well tested in Java.
> For instance, in my previous example I wondered if we would name lots of =
loops a/b/c and then make mistakes on which one we were referring to. It mi=
ght not be major concern but it's stuff to consider.
That's only because you changed the proposal to allow duplicate names. You =
only burned your own strawman.
> But without challenging it's usefulness with some metric, people won't co=
me forward with their best arguments on for and against to really be able t=
o tell the true value of something.
So... if something looks good, then we need a new metric to challenge it?
> I don't like complex code for processing something that's found in a loop=
, stuck doing that processing way nested in the loop(s). But I often need t=
he flag out of the loop to decide if I should do that process when I get th=
ere as well as to exit. This seems to somewhat mitigate the redundancy I'm =
inferring from your argument of, in many cases.
Ah, loops which succeed early or do nothing. break doesn't cut it, but you =
don't don't need a condition variable if you use goto. There are many other=
ways to factor that, it's not really a recommendation. But personally, I a=
void "found it already" flags.
> It's good it gets a wider discussion though, I enjoy reading peoples posi=
tions on it. I hope the explicit switch type ideas get more discussion time=
too, despite it being rejected.
Fortunately, discussion time lasts as long as we don't destroy the language=
:) . Hopefully decades more.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_085288A7-13A4-4776-BED8-40D1315057A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–04, at 9:39 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmisoc=
pp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"><div dir=3D"ltr">\"I would barely use this feature=
" is my starting proposition on this feature, and it's exactly a =
reasonable and right metric to begin to apply here. it defin=
itely doesn't miss the point.</div></blockquote><div><br></div><div>Do you =
write parsers? Do you write optimized numeric solvers (which tend to also l=
ook like parsers)?</div><div><br></div><div>You can’t apply that metr=
ic unless you’re God. If someone else says something is useful, it&rs=
quo;s better to give the benefit of the doubt.</div><br><blockquote type=3D=
"cite"><div dir=3D"ltr"><div>If we add the feature and we later find it has=
as many issues as it solves, we haven't really gone anywhere other than co=
mplicating the language.</div></div></blockquote><div><br></div><div>Nobody=
’s suggested any risk. The feature has been well tested in Java.</div=
><br><blockquote type=3D"cite"><div dir=3D"ltr"><div>For instance, in my pr=
evious example I wondered if we would name lots of loops a/b/c and then mak=
e mistakes on which one we were referring to. It might not be major concern=
but it's stuff to consider.</div></div></blockquote><div><br></div><div>Th=
at’s only because you changed the proposal to allow duplicate names. =
You only burned your own strawman.</div><br><blockquote type=3D"cite"><div =
dir=3D"ltr"><div>But without challenging it's usefulness with some metric, =
people won't come forward with their best arguments on for and against=
to really be able to tell the true value of something.</div></div></blockq=
uote><div><br></div><div>So… if something looks good, then we need a=
new metric to challenge it?</div><br><blockquote type=3D"cite"><div dir=3D=
"ltr"><div><div>I don't like complex code for processing something tha=
t's found in a loop, stuck doing that processing way nested in the loop(s).=
But I often need the flag out of the loop to decide if I should do that pr=
ocess when I get there as well as to exit. This seems to somewhat mitigate =
the redundancy I'm inferring from your argument of, in many cases=
..</div></div></div></blockquote><div><br></div><div>Ah, loops which succeed=
early or do nothing. <font face=3D"Courier">break</font> doesn't cut it, b=
ut you don’t don’t need a condition variable if you use <font f=
ace=3D"Courier">goto</font>. There are many other ways to factor that, it&r=
squo;s not really a recommendation. But personally, I avoid “found it=
already” flags.</div><br><blockquote type=3D"cite"><div dir=3D"ltr">=
<div><div>It's good it gets a wider discussion though, I enjoy reading peop=
les positions on it. I hope the explicit switch type ideas get more discuss=
ion time too, despite it being rejected.</div></div></div></blockquote><br>=
</div><div>Fortunately, discussion time lasts as long as we don’t des=
troy the language :) . Hopefully decades more.</div><br></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_085288A7-13A4-4776-BED8-40D1315057A2--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 20:21:07 -0700 (PDT)
Raw View
------=_Part_2949_2055609334.1407122467595
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, August 4, 2014 2:08:57 PM UTC+12, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9304, at 9:39 AM, gmis...@gmail.com <javascript:=
> wrote:
>
> \"I would barely use this feature" is my starting proposition on this=20
> feature, and it's exactly a reasonable and right metric to begin to apply=
=20
> here. it definitely doesn't miss the point.
>
>
> Do you write parsers? Do you write optimized numeric solvers (which tend=
=20
> to also look like parsers)?
>
> You can=E2=80=99t apply that metric unless you=E2=80=99re God. If someone=
else says=20
> something is useful, it=E2=80=99s better to give the benefit of the doubt=
..
>
You're right which is exactly what I said=20
"That I feel I would barely use the proposed feature doesn't mean anything=
=20
at this stage though, it's my initial suggestion not a definitive statement=
=20
and it's a reasonable starting proposition that needs to be tested. If=20
people demonstrate that I could do more with the feature that I can=20
currently can imagine, I'd change my tune on my mild opposition to the=20
feature."
which you failed to quote. But I'm entitled to express my reasonable=20
opinion that I never use it so is it useful as much as you are entitled to=
=20
express your opinion that you would use it which is why I expressed my=20
opinion and was encouraging the counter people to chime in to see where=20
there was consensus. Your choice of quote selection seems to lose that=20
perspective I had.
It's also why I said we could use more stats on how good this feature=20
really is in practice, and I haven't seen any, but nor have any.
If there was some that would be the best argument either way in my opinion.
Your argument thus far isn't advancing the status quo in my opinion.
=20
>
> If we add the feature and we later find it has as many issues as it=20
> solves, we haven't really gone anywhere other than complicating the=20
> language.
>
>
> Nobody=E2=80=99s suggested any risk. The feature has been well tested in =
Java.
>
Say's who? If it was well tested, everybody would agree we=20
need this feature in C++, I haven't seen that consensus but sure it may=20
develop. But until then I'm not sure what you are basing that statement of=
=20
fact on.=20
>
> For instance, in my previous example I wondered if we would name lots of=
=20
> loops a/b/c and then make mistakes on which one we were referring to. It=
=20
> might not be major concern but it's stuff to consider.
>
>
> That=E2=80=99s only because you changed the proposal to allow duplicate n=
ames. You=20
> only burned your own strawman.
>
Well you have to get people challenging the problem space somehow.=20
>
> But without challenging it's usefulness with some metric, people won't=20
> come forward with their best arguments on for and against to really be=20
> able to tell the true value of something.=20
>
> So=E2=80=A6 if something looks good, then we need a new metric to challen=
ge it?
>
Looks good to who? But I don't get your point here.=20
>
> I don't like complex code for processing something that's found in a loop=
,=20
> stuck doing that processing way nested in the loop(s). But I often need t=
he=20
> flag out of the loop to decide if I should do that process when I get the=
re=20
> as well as to exit. This seems to somewhat mitigate the redundancy I'm=20
> inferring from your argument of, in many cases.
>
>
> Ah, loops which succeed early or do nothing. break doesn't cut it, but=20
> you don=E2=80=99t don=E2=80=99t need a condition variable if you use goto=
.. There are many=20
> other ways to factor that, it=E2=80=99s not really a recommendation. But=
=20
> personally, I avoid =E2=80=9Cfound it already=E2=80=9D flags.
>
Not sure what your focus is here, but people don't like to use goto which=
=20
is a problem.
break x / continue x would encourage those people who don't like to use=20
goto to get what they want another way.
I'm just not sure that's a good enough reason to add the feature, but it=20
might be, because goto has such a bad image.
> It's good it gets a wider discussion though, I enjoy reading peoples=20
> positions on it. I hope the explicit switch type ideas get more discussio=
n=20
> time too, despite it being rejected.
>
>
> Fortunately, discussion time lasts as long as we don=E2=80=99t destroy th=
e=20
> language :) . Hopefully decades more.
>
> Ha ha, too true. We need to build concurrency into the language too early=
=20
to damage it successfully I imagine. lol=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_2949_2055609334.1407122467595
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 4, 2014 2:08:57 PM UTC+12, David=
Krauss wrote:<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-l=
eft-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: bre=
ak-word;"><br><div><div>On 2014=E2=80=9308=E2=80=9304, at 9:39 AM, <a onmou=
sedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"uVXNdYCv1K4J">gmis...@gmail.com</a> wrote:</div><br><blockqu=
ote type=3D"cite"><div dir=3D"ltr">\"I would barely use this feature"&=
nbsp;is my starting proposition on this feature, and it's exactly a re=
asonable and right metric to begin to apply here. it definit=
ely doesn't miss the point.</div></blockquote><div><br></div><div>Do you wr=
ite parsers? Do you write optimized numeric solvers (which tend to also loo=
k like parsers)?</div><div><br></div><div>You can=E2=80=99t apply that metr=
ic unless you=E2=80=99re God. If someone else says something is useful, it=
=E2=80=99s better to give the benefit of the doubt.</div></div></div></bloc=
kquote><div><br></div><div>You're right which is exactly what I said </div>=
<div><br></div><div>"That I feel I would barely use the proposed feature&nb=
sp;doesn't mean anything at this stage though, it's my initial su=
ggestion not a definitive statement and it's a reasonable starting proposit=
ion that needs to be tested. If people demonstrate that I could do mor=
e with the feature that I can currently can imagine, I'd change my tune on =
my mild opposition to the feature."</div><div><br></div><div>which you fail=
ed to quote. But I'm entitled to express my reasonable opinion that I never=
use it so is it useful as much as you are entitled to express your opinion=
that you would use it which is why I expressed my opinion and was encourag=
ing the counter people to chime in to see where there was consensus. Your&n=
bsp;choice of quote selection seems to lose that perspective I had.</d=
iv><div><br></div><div>It's also why I said we could use more stats on how =
good this feature really is in practice, and I haven't seen any, but nor ha=
ve any.</div><div>If there was some that would be the best argument either =
way in my opinion.</div><div>Your argument thus far isn't advancing the sta=
tus quo in my opinion.</div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-colo=
r: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;"><=
div style=3D"-ms-word-wrap: break-word;"><div><br><blockquote type=3D"cite"=
><div dir=3D"ltr"><div>If we add the feature and we later find it has as ma=
ny issues as it solves, we haven't really gone anywhere other than complica=
ting the language.</div></div></blockquote><div><br></div><div>Nobody=E2=80=
=99s suggested any risk. The feature has been well tested in Java.</div></d=
iv></div></blockquote><div>Say's who? If it was well tested, everybody woul=
d agree we need this feature in C++, I haven't seen that consensu=
s but sure it may develop. But until then I'm not sure what you a=
re basing that statement of fact on. </div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-c=
olor: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;=
"><div style=3D"-ms-word-wrap: break-word;"><div><br><blockquote type=3D"ci=
te"><div dir=3D"ltr"><div>For instance, in my previous example I wondered i=
f we would name lots of loops a/b/c and then make mistakes on which one we =
were referring to. It might not be major concern but it's stuff to consider=
..</div></div></blockquote><div><br></div><div>That=E2=80=99s only because y=
ou changed the proposal to allow duplicate names. You only burned your own =
strawman.</div></div></div></blockquote><div>Well you have to get people&nb=
sp;challenging the problem space somehow. </div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div style=3D"-ms-word-wrap: break-word;"><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div>But without challenging it's usefulness=
with some metric, people won't come forward with their best arguments =
;on for and against to really be able to tell the true value of someth=
ing. </div></div></blockquote></div></div></blockquote><blockquote cla=
ss=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-s=
tyle: solid;"><div style=3D"-ms-word-wrap: break-word;"><div><div>So=E2=80=
=A6 if something looks good, then we need a new metric to challenge it?</di=
v></div></div></blockquote><div>Looks good to who? But I don't get your poi=
nt here. </div><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); bo=
rder-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wra=
p: break-word;"><div><br><blockquote type=3D"cite"><div dir=3D"ltr"><div><d=
iv>I don't like complex code for processing something that's found in =
a loop, stuck doing that processing way nested in the loop(s). But I often =
need the flag out of the loop to decide if I should do that process when I =
get there as well as to exit. This seems to somewhat mitigate the redundanc=
y I'm inferring from your argument of, in many cases.</div></div>=
</div></blockquote><div><br></div><div>Ah, loops which succeed early or do =
nothing. <font face=3D"Courier">break</font> doesn't cut it, but you don=E2=
=80=99t don=E2=80=99t need a condition variable if you use <font face=3D"Co=
urier">goto</font>. There are many other ways to factor that, it=E2=80=99s =
not really a recommendation. But personally, I avoid =E2=80=9Cfound it alre=
ady=E2=80=9D flags.</div></div></div></blockquote><div><br></div><div>Not s=
ure what your focus is here, but people don't like to use goto which i=
s a problem.</div><div>break x / continue x would encourage those people wh=
o don't like to use goto to get what they want another way.</div><div>I'm j=
ust not sure that's a good enough reason to add the feature, but it might b=
e, because goto has such a bad image.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; bor=
der-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-sty=
le: solid;"><div style=3D"-ms-word-wrap: break-word;"><div><br><blockquote =
type=3D"cite"><div dir=3D"ltr"><div><div>It's good it gets a wider discussi=
on though, I enjoy reading peoples positions on it. I hope the explicit swi=
tch type ideas get more discussion time too, despite it being rejected.</di=
v></div></div></blockquote><br></div><div>Fortunately, discussion time last=
s as long as we don=E2=80=99t destroy the language :) . Hopefully decades m=
ore.</div><br></div></blockquote><div>Ha ha, too true. We need to buil=
d concurrency into the language too early to damage it successfully I imagi=
ne. lol </div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2949_2055609334.1407122467595--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 4 Aug 2014 12:04:22 +0800
Raw View
--Apple-Mail=_596B4940-709A-4A18-92EC-7DEB3512F499
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-08-04, at 11:21 AM, gmisocpp@gmail.com wrote:
> It's also why I said we could use more stats on how good this feature rea=
lly is in practice, and I haven't seen any, but nor have any.
How often do codebase stats support any C++ proposal? We generally make due=
with anecdotes and reasoning, by necessity. Mind that the language is not =
designed around the common case, it's designed to provide safety in a wide =
variety of applications.
It sounds like you're dressing an unattainable expectation in terms relatin=
g to common practice. Lack of stats doesn't enter into the "status quo," be=
cause it's a poor metric that we don't generally use.
However, if I ask Google, it sends me to Wikipedia, where I find:
> Situations in which goto is often useful include:
> ...
> * for implementing multi-level break and continue if not directly support=
ed in the language; this is a common idiom in C.[12] Although Java reserves=
the goto keyword, it doesn't actually implement it. Instead, Java implemen=
ts labelled break and labelled continue statements.[28] According to the Ja=
va documentation, the use of gotos for multi-level breaks was the most comm=
on (90%) use of gotos in C.[29] Java was not first language to take this ap=
proach--forbidding goto, but providing multi-level breaks-- the BLISS progr=
amming language (more precisely the BLISS-11 version thereof) preceded it i=
n this respect.[30]
That's fairly statistical, and you can check the sources, although such lan=
guage research tends to be biased.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_596B4940-709A-4A18-92EC-7DEB3512F499
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;08–04, at 11:21 AM, <a href=3D"mailto:gmisocpp@gmail.com">gmiso=
cpp@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 12px;=
font-style: normal; font-variant: normal; font-weight: normal; letter-spac=
ing: normal; line-height: normal; orphans: auto; text-align: start; text-in=
dent: 0px; text-transform: none; white-space: normal; widows: auto; word-sp=
acing: 0px; -webkit-text-stroke-width: 0px;">It's also why I said we could =
use more stats on how good this feature really is in practice, and I haven'=
t seen any, but nor have any.</div></blockquote></div><br><div>How often do=
codebase stats support any C++ proposal? We generally make due with anecdo=
tes and reasoning, by necessity. Mind that the language is not designed aro=
und the common case, it’s designed to provide safety in a wide variet=
y of applications.</div><div><br></div><div>It sounds like you’re dre=
ssing an unattainable expectation in terms relating to common practice. Lac=
k of stats doesn’t enter into the “status quo,” because i=
t’s a poor metric that we don’t generally use.</div><div><br></=
div><div>However, if I ask Google, it sends me to <a href=3D"http://en=
..wikipedia.org/wiki/Goto#Common_usage_patterns_of_Goto">Wikipedia</a>, wher=
e I find:</div><div><br></div><div><div></div></div><blockquote type=3D"cit=
e"><div><div>Situations in which goto is often useful include:</div></div><=
/blockquote><blockquote type=3D"cite"><div><div>…</div></div></block=
quote><blockquote type=3D"cite"><div><div>• for implementing multi-lev=
el break and continue if not directly supported in the language; this is a =
common idiom in C.[12] Although Java reserves the goto keyword, i=
t doesn't actually implement it. Instead, Java implements labelled bre=
ak and labelled continue statements.[28] According to the Java do=
cumentation, the use of gotos for multi-level breaks was the most common (9=
0%) use of gotos in C.[29] Java was not first language to take th=
is approach—forbidding goto, but providing multi-level breaks— =
the BLISS programming language (more precisely the BLISS-11 =
version thereof) preceded it in this respect.[30]</div></div></blockquote><=
div><br></div><div>That’s fairly statistical, and you can check the s=
ources, although such language research tends to be biased.</div><div><br><=
/div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_596B4940-709A-4A18-92EC-7DEB3512F499--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 21:53:15 -0700 (PDT)
Raw View
------=_Part_2025_2092901771.1407127995456
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, August 4, 2014 4:04:32 PM UTC+12, David Krauss wrote:
>
>
> On 2014=E2=80=9308=E2=80=9304, at 11:21 AM, gmis...@gmail.com <javascript=
:> wrote:
>
> It's also why I said we could use more stats on how good this feature=20
> really is in practice, and I haven't seen any, but nor have any.
>
>
> How often do codebase stats support any C++ proposal? We generally make=
=20
> due with anecdotes and reasoning, by necessity. Mind that the language is=
=20
> not designed around the common case, it=E2=80=99s designed to provide saf=
ety in a=20
> wide variety of applications.
>
> It sounds like you=E2=80=99re dressing an unattainable expectation in ter=
ms=20
> relating to common practice. Lack of stats doesn=E2=80=99t enter into the=
=E2=80=9Cstatus=20
> quo,=E2=80=9D because it=E2=80=99s a poor metric that we don=E2=80=99t ge=
nerally use.
>
> However, if I ask Google, it sends me to Wikipedia=20
> <http://en.wikipedia.org/wiki/Goto#Common_usage_patterns_of_Goto>, where=
=20
> I find:
>
> Situations in which goto is often useful include:
>
> =E2=80=A6
>
> =E2=80=A2 for implementing multi-level break and continue if not directly=
=20
> supported in the language; this is a common idiom in C.[12] Although Java=
=20
> reserves the goto keyword, it doesn't actually implement it. Instead, Jav=
a=20
> implements labelled break and labelled continue statements.[28] According=
=20
> to the Java documentation, the use of gotos for multi-level breaks was th=
e=20
> most common (90%) use of gotos in C.[29] Java was not first language to=
=20
> take this approach=E2=80=94forbidding goto, but providing multi-level bre=
aks=E2=80=94=20
> the BLISS programming language (more precisely the BLISS-11 version=20
> thereof) preceded it in this respect.[30]
>
>
> That=E2=80=99s fairly statistical, and you can check the sources, althoug=
h such=20
> language research tends to be biased.
>
Yes I agree that introducing break loop x to avoid goto because goto has a=
=20
stigma so people don't use it even when using gotoo would be more=20
appropriate than introducing a bunch of bogus variables to do the job=20
instead, is the most compelling thing about the feature. 90% sounds like a=
=20
large value unless you know what it's 90% of.
In my code, 90% of about two likely use cases ever, Isn't a big number. I=
=20
appreciate in your code base that might be different, but that's what=20
people are here to chime in with. Hopefully they have all parts of that 90%=
=20
equation so we can talk about what 90% actually is, because 90% of not a=20
lot is not a lot. 90% of a lot, is a lot. Once someone has some clear=20
indication of which 90% factor we are talking about here, it might be more=
=20
consensus forming. But I haven't seen that yet.
--=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_2025_2092901771.1407127995456
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, August 4, 2014 4:04:32 PM UTC+12, David=
Krauss wrote:<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-l=
eft-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wrap: bre=
ak-word;"><br><div><div>On 2014=E2=80=9308=E2=80=9304, at 11:21 AM, <a onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;" href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"j4c92r5uMq0J">gmis...@gmail.com</a> wrote:</div><br><blockq=
uote type=3D"cite"><div style=3D"font: 12px/normal Helvetica; text-transfor=
m: none; text-indent: 0px; letter-spacing: normal; word-spacing: 0px; white=
-space: normal; font-size-adjust: none; font-stretch: normal;">It's also wh=
y I said we could use more stats on how good this feature really is in prac=
tice, and I haven't seen any, but nor have any.</div></blockquote></div><br=
><div>How often do codebase stats support any C++ proposal? We generally ma=
ke due with anecdotes and reasoning, by necessity. Mind that the language i=
s not designed around the common case, it=E2=80=99s designed to provide saf=
ety in a wide variety of applications.</div><div><br></div><div>It sounds l=
ike you=E2=80=99re dressing an unattainable expectation in terms relating t=
o common practice. Lack of stats doesn=E2=80=99t enter into the =E2=80=9Cst=
atus quo,=E2=80=9D because it=E2=80=99s a poor metric that we don=E2=80=99t=
generally use.</div><div><br></div><div>However, if I ask Google, it sends=
me to <a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75ht=
tp%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGoto%23Common_usage_patterns_of_Goto\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNHMDGx9PTX_6KbdyJWD50M5NOdTCQ';return true=
;" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fen.wi=
kipedia.org%2Fwiki%2FGoto%23Common_usage_patterns_of_Goto\46sa\75D\46sntz\0=
751\46usg\75AFQjCNHMDGx9PTX_6KbdyJWD50M5NOdTCQ';return true;" href=3D"http:=
//en.wikipedia.org/wiki/Goto#Common_usage_patterns_of_Goto" target=3D"_blan=
k">Wikipedia</a>, where I find:</div><div><br></div><div><div></div></div><=
blockquote type=3D"cite"><div><div>Situations in which goto is often useful=
include:</div></div></blockquote><blockquote type=3D"cite"><div><div>=E2=
=80=A6</div></div></blockquote><blockquote type=3D"cite"><div><div>=E2=80=
=A2 for implementing multi-level break and continue if not directly support=
ed in the language; this is a common idiom in C.[12] Although Jav=
a reserves the goto keyword, it doesn't actually implement it. Instead=
, Java implements labelled break and labelled continue statements.[28]=
<wbr>According to the Java documentation, the use of gotos for multi-=
level breaks was the most common (90%) use of gotos in C.[29] Jav=
a was not first language to take this approach=E2=80=94forbidding goto, but=
providing multi-level breaks=E2=80=94 the BLISS programming =
;language (more precisely the BLISS-11 version thereof) preceded it in this=
respect.[30]</div></div></blockquote><div><br></div><div>That=E2=80=99s fa=
irly statistical, and you can check the sources, although such language res=
earch tends to be biased.</div></div></blockquote><div><br></div><div>Yes I=
agree that introducing break loop x to avoid goto because goto has a =
stigma so people don't use it even when using gotoo would b=
e more appropriate than introducing a bunch of bogus va=
riables to do the job instead, is the most compelling thing about=
the feature. 90% sounds like a large value unless you know what it's =
90% of.</div><div><br></div><div>In my code, 90% of about two likely use ca=
ses ever, Isn't a big number. I appreciate in your code base that migh=
t be different, but that's what people are here to chime in with. Hopefully=
they have all parts of that 90% equation so we can talk about what 90% act=
ually is, because 90% of not a lot is not a lot. 90% of a lot, is a lot. On=
ce someone has some clear indication of which 90% factor we are talking abo=
ut here, it might be more consensus forming. But I haven't seen that yet.</=
div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2025_2092901771.1407127995456--
.
Author: gmisocpp@gmail.com
Date: Sun, 3 Aug 2014 21:59:37 -0700 (PDT)
Raw View
------=_Part_3015_1395520556.1407128377840
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> =E2=80=A2 for implementing multi-level break and continue if not directly=
=20
> supported in the language; this is a common idiom in C.[12] Although Java=
=20
> reserves the goto keyword, it doesn't actually implement it. Instead, Jav=
a=20
> implements labelled break and labelled continue statements.[28] According=
=20
> to the Java documentation, the use of gotos for multi-level breaks was th=
e=20
> most common (90%) use of gotos in C.[29] Java was not first language to=
=20
> take this approach=E2=80=94forbidding goto, but providing multi-level bre=
aks=E2=80=94=20
> the BLISS programming language (more precisely the BLISS-11 version=20
> thereof) preceded it in this respect.[30]
>
>
>
> I might also add that it's not 100% clear to me that the 90% of goto's=20
they removed were actually bad. It might well be that the people that=20
invented this feature to replace the goto might have been suffering from=20
the same over zealous fear of goto in the first place. Maybe we just need a=
=20
"goto's not so bad" campaign instead, especially if that 90% value turns=20
out to be a small number.
--=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_3015_1395520556.1407128377840
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;"><div style=3D"-ms-word-wr=
ap: break-word;"><blockquote type=3D"cite"><div><div>=E2=80=A2 for implemen=
ting multi-level break and continue if not directly supported in the langua=
ge; this is a common idiom in C.[12] Although Java reserves the g=
oto keyword, it doesn't actually implement it. Instead, Java implement=
s labelled break and labelled continue statements.[28] <wbr>Accor=
ding to the Java documentation, the use of gotos for multi-level breaks was=
the most common (90%) use of gotos in C.[29] Java was not first =
language to take this approach=E2=80=94forbidding goto, but providing multi=
-level breaks=E2=80=94 the BLISS programming language (more =
precisely the BLISS-11 version thereof) preceded it in this respect.[30]</d=
iv></div></blockquote><div><br></div><div><br></div></div></blockquote><div=
>I might also add that it's not 100% clear to me that the 90% of goto'=
s they removed were actually bad. It might well be that the people tha=
t invented this feature to replace the goto might have been suffering =
from the same over zealous fear of goto in the first place. Maybe=
we just need a "goto's not so bad" campaign instead, especially if that 90=
% value turns out to be a small number.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3015_1395520556.1407128377840--
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Mon, 4 Aug 2014 08:28:34 -0700
Raw View
On Sun, Aug 3, 2014 at 9:59 PM, <gmisocpp@gmail.com> wrote:
> I might also add that it's not 100% clear to me that the 90% of goto's they
> removed were actually bad. It might well be that the people that invented
> this feature to replace the goto might have been suffering from the same
> over zealous fear of goto in the first place. Maybe we just need a "goto's
> not so bad" campaign instead, especially if that 90% value turns out to be a
> small number.
This is similar to the same arguments one could use for `new`. It
certainly can be used responsibly and correctly (as evidenced by 20
years of software products released before C++11) but it's so easily
used incorrectly (or its partner `delete` is used/unused incorrectly,
at least) that we now recommend to never ever use the operator.
Likewise, `goto` can be used in ways which increase readability bu
it's far too easy (especially for junior engineers) to use in ways
that cause bugs or make code incomprehensible. The labeled-break
feature is a way of allowing a goto-like construct that is much more
limited and hence less dangerous (since you can't jump into the middle
of unrelated scopes).
--
Sean Middleditch
http://seanmiddleditch.com
--
---
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: Myriachan <myriachan@gmail.com>
Date: Mon, 4 Aug 2014 12:22:05 -0700 (PDT)
Raw View
------=_Part_2723_404309593.1407180125704
Content-Type: text/plain; charset=UTF-8
On Monday, August 4, 2014 8:28:39 AM UTC-7, Sean Middleditch wrote:
>
> This is similar to the same arguments one could use for `new`. It
> certainly can be used responsibly and correctly (as evidenced by 20
> years of software products released before C++11) but it's so easily
> used incorrectly (or its partner `delete` is used/unused incorrectly,
> at least) that we now recommend to never ever use the operator.
>
> Likewise, `goto` can be used in ways which increase readability bu
> it's far too easy (especially for junior engineers) to use in ways
> that cause bugs or make code incomprehensible. The labeled-break
> feature is a way of allowing a goto-like construct that is much more
> limited and hence less dangerous (since you can't jump into the middle
> of unrelated scopes).
>
I completely agree here. I'm not going to go cry about it if labeled break/
continue isn't implemented, but it's a convenience feature that is less
prone to shooting oneself in one's foot. The cost and risk of the feature
seems very low, it matches other languages, and it fills a void left by the
lack of goto in relaxed constexpr.
By the way, does the runtime-bound array spec mention that goto into a
scope past the declaration of a runtime-bound array is ill-formed? It
certainly ought to be.
--
---
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_2723_404309593.1407180125704
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, August 4, 2014 8:28:39 AM UTC-7, Sean Middledit=
ch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">This is similar to th=
e same arguments one could use for `new`. It
<br>certainly can be used responsibly and correctly (as evidenced by 20
<br>years of software products released before C++11) but it's so easily
<br>used incorrectly (or its partner `delete` is used/unused incorrectly,
<br>at least) that we now recommend to never ever use the operator.
<br>
<br>Likewise, `goto` can be used in ways which increase readability bu
<br>it's far too easy (especially for junior engineers) to use in ways
<br>that cause bugs or make code incomprehensible. The labeled-break
<br>feature is a way of allowing a goto-like construct that is much more
<br>limited and hence less dangerous (since you can't jump into the middle
<br>of unrelated scopes).
<br></blockquote><div><br>I completely agree here. I'm not going to g=
o cry about it if labeled <span style=3D"font-family: courier new,monospace=
;">break</span>/<span style=3D"font-family: courier new,monospace;">continu=
e</span> isn't implemented, but it's a convenience feature that is less pro=
ne to shooting oneself in one's foot. The cost and risk of the featur=
e seems very low, it matches other languages, and it fills a void left by t=
he lack of <span style=3D"font-family: courier new,monospace;">goto</span> =
in relaxed <span style=3D"font-family: courier new,monospace;">constexpr</s=
pan>.<br><br>By the way, does the runtime-bound array spec mention that got=
o into a scope past the declaration of a runtime-bound array is ill-formed?=
It certainly ought to be.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2723_404309593.1407180125704--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 4 Aug 2014 22:36:12 +0300
Raw View
On 4 August 2014 22:22, Myriachan <myriachan@gmail.com> wrote:
> I completely agree here. I'm not going to go cry about it if labeled
> break/continue isn't implemented, but it's a convenience feature that is
> less prone to shooting oneself in one's foot. The cost and risk of the
> feature seems very low, it matches other languages, and it fills a void left
> by the lack of goto in relaxed constexpr.
I don't see much risk in it. The cost is an interesting question; I can easily
count six compilers and two static analysis tools from the usual committee
attendees, and a handful more of both compilers and tools outside the
usual attendees that need to cope. So, it's more a question of the
benefit/cost ratio, and for this particular idea, that ratio seems low.
--
---
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: Hyman Rosen <hyman.rosen@gmail.com>
Date: Mon, 4 Aug 2014 16:17:24 -0400
Raw View
--047d7b5da6c78d65c604ffd36e58
Content-Type: text/plain; charset=UTF-8
Ada had multi-level loop exits
<http://www.adaic.org/resources/add_content/standards/05aarm/html/AA-5-7.html>
decades ago.
On Mon, Aug 4, 2014 at 3:36 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 4 August 2014 22:22, Myriachan <myriachan@gmail.com> wrote:
> > I completely agree here. I'm not going to go cry about it if labeled
> > break/continue isn't implemented, but it's a convenience feature that is
> > less prone to shooting oneself in one's foot. The cost and risk of the
> > feature seems very low, it matches other languages, and it fills a void
> left
> > by the lack of goto in relaxed constexpr.
>
>
> I don't see much risk in it. The cost is an interesting question; I can
> easily
> count six compilers and two static analysis tools from the usual committee
> attendees, and a handful more of both compilers and tools outside the
> usual attendees that need to cope. So, it's more a question of the
> benefit/cost ratio, and for this particular idea, that ratio seems low.
>
> --
>
> ---
> 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/.
--047d7b5da6c78d65c604ffd36e58
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ada had <a href=3D"http://www.adaic.org/resources/add_cont=
ent/standards/05aarm/html/AA-5-7.html">multi-level loop exits</a> decades a=
go.</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On M=
on, Aug 4, 2014 at 3:36 PM, Ville Voutilainen <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:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 4 August 2014 22:22, Myri=
achan <<a href=3D"mailto:myriachan@gmail.com">myriachan@gmail.com</a>>=
; wrote:<br>
> I completely agree here. =C2=A0I'm not going to go cry about it if=
labeled<br>
> break/continue isn't implemented, but it's a convenience featu=
re that is<br>
> less prone to shooting oneself in one's foot. =C2=A0The cost and r=
isk of the<br>
> feature seems very low, it matches other languages, and it fills a voi=
d left<br>
> by the lack of goto in relaxed constexpr.<br>
<br>
<br>
</div>I don't see much risk in it. The cost is an interesting question;=
I can easily<br>
count six compilers and two static analysis tools from the usual committee<=
br>
attendees, and a handful more of both compilers and tools outside the<br>
usual attendees that need to cope. So, it's more a question of the<br>
benefit/cost ratio, and for this particular idea, that ratio seems low.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b5da6c78d65c604ffd36e58--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 5 Aug 2014 00:01:44 +0300
Raw View
On 4 August 2014 23:17, Hyman Rosen <hyman.rosen@gmail.com> wrote:
> Ada had multi-level loop exits decades ago.
That's nice, but if EWG didn't consider the labeled breaks in Java a sufficient
motivation to add a similar facility to C++, do you think Ada as an example of
existing practice would fare any better? Or that it would contribute
significantly
as an additional example of existing practice?
--
---
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: gmisocpp@gmail.com
Date: Mon, 4 Aug 2014 16:09:19 -0700 (PDT)
Raw View
------=_Part_3_504782852.1407193759600
Content-Type: text/plain; charset=UTF-8
Hi
On Tuesday, August 5, 2014 3:28:39 AM UTC+12, Sean Middleditch wrote:
>
> On Sun, Aug 3, 2014 at 9:59 PM, <gmis...@gmail.com <javascript:>> wrote:
> > I might also add that it's not 100% clear to me that the 90% of goto's
> they
> > removed were actually bad. It might well be that the people that
> invented
> > this feature to replace the goto might have been suffering from the same
> > over zealous fear of goto in the first place. Maybe we just need a
> "goto's
> > not so bad" campaign instead, especially if that 90% value turns out to
> be a
> > small number.
>
> This is similar to the same arguments one could use for `new`. It
> certainly can be used responsibly and correctly (as evidenced by 20
> years of software products released before C++11) but it's so easily
> used incorrectly (or its partner `delete` is used/unused incorrectly,
> at least) that we now recommend to never ever use the operator.
>
Well, one could make that argument, but I don't at all see why you would.
I'm assuming you are talking about comparing replacing new with
std::make_unque compared to replacing goto x with break x?
The reason why I wouldn't remotely make that comparison is central to my
whole thinking on this subject.
In my experience, I've gone through a lot of code replacing new with
unique_ptr and it was beneficial.
90% of x was a lot and the value was clear.
With the goto, I wouldn't have a lot/any code to replace with goto x with
break x, so 90% of x is not a lot.
So the two are completely different things to me for that very important
reason.
If a large number of people convince me that things are different on their
code bases, I'd be surprised.
But it's not impossible I don't see the worlds code bases.
But for me, unique_ptr seems to have definitely proved it's worth in
replacing new. A lot of code bases I've seen do benefit from it.
With goto to break x conversions, I imagine the code bases that would gain
from the conversion would me orders of magnitude smaller.
This is the key measure of a feature's worth to me. If the goto / break x
yielded even a fraction of as much actual conversion as new to unique_ptr,
I'd be more excited by the feature. I suspect it won't, But that's why I
wouldn't remotely compare the two and is the only metric on which I can see
being convinced the two are remotely comparable for your analogy purpose.
Tat's why the conversion stat's of what break x has actually yielded for
other language is of so much interest to me.
That's why I wouldn't remotely try to make the type of comparison you are
promoting, I don't think it makes sense because I don't think the
conversion results would be remotely comparable and if we had stats I think
it would show that.
But I do appreciate other peoples experiences with their code bases might
be radically different but without stats I think it's hard for anyone to
argue credibly either way.
I don't see wild risk for introducing break x, I just think I'm not likely
to use it that often and I'm convinced that will be the use case for the
majority of people by way far. If new features in C++ like constexpr make
break x more necessary than that would change my thinking.
But if it helps a few people who write parsers though, I wouldn't object to
it being added, but I'm mildly against. and see myself only changing to
mildly for at best without more evidence of the need. That every other
language has the feature isn't compelling for me without stats of people
actually using it.
> Likewise, `goto` can be used in ways which increase readability bu
> it's far too easy (especially for junior engineers) to use in ways
> that cause bugs or make code incomprehensible. The labeled-break
> feature is a way of allowing a goto-like construct that is much more
> limited and hence less dangerous (since you can't jump into the middle
> of unrelated scopes).
>
I never saw this problem, I wasn't tempted to abuse goto myself when
learning C++ and I didn't see it abused (much) in any code bases I worked
on ever, certainly not in recent times, so I can't relate. I might have
been lucky. But if that's what you see, I can't argue with your experience,
but that was mine.
I'll be interested in where the consensus arrives at for this feature. From
the sounds of people, the consensus for the feature might exist here. How
that translates elsewhere I don't know. I think the feature needs stats
proof for me to get excited about it for other people, but it's not a risky
feature so maybe that doesn't matter. If it goes in and isn't used much, if
there is no harm, so what, I guess.
I'd be more excited about a more powerful yet brief switch if it could be
done without making a mockery of things, but that seems way harder with way
more risk.
> --
> Sean Middleditch
> http://seanmiddleditch.com
>
--
---
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_3_504782852.1407193759600
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi<br><br>On Tuesday, August 5, 2014 3:28:39 AM UTC+12, Se=
an Middleditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px=
0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); b=
order-left-width: 1px; border-left-style: solid;">On Sun, Aug 3, 2014 at 9:=
59 PM, <<a onmousedown=3D"this.href=3D'javascript:';return true;" =
onclick=3D"this.href=3D'javascript:';return true;" href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"EG1rqdHA3ucJ">gmis...@gmail.com</a>=
> wrote:
<br>> I might also add that it's not 100% clear to me that the 90% of go=
to's they
<br>> removed were actually bad. It might well be that the people that i=
nvented
<br>> this feature to replace the goto might have been suffering from th=
e same
<br>> over zealous fear of goto in the first place. Maybe we just need a=
"goto's
<br>> not so bad" campaign instead, especially if that 90% value turns o=
ut to be a
<br>> small number.
<br>
<br>This is similar to the same arguments one could use for `new`. It
<br>certainly can be used responsibly and correctly (as evidenced by 20
<br>years of software products released before C++11) but it's so easily
<br>used incorrectly (or its partner `delete` is used/unused incorrectly,
<br>at least) that we now recommend to never ever use the operator.
<br></blockquote><div><br></div><div>Well, one could make that argument, bu=
t I don't at all see why you would.</div><div>I'm assuming you are talking =
about comparing replacing new with std::make_unque compared to re=
placing goto x with break x?</div><div><br></div><div>The reason why I=
wouldn't remotely make that comparison is central to my whole thinkin=
g on this subject.</div><div>In my experience, I've gone through a lot=
of code replacing new with unique_ptr and it was beneficial.</div><di=
v>90% of x was a lot and the value was clear.</div><div><br></div><div>With=
the goto, I wouldn't have a lot/any code to replace with goto x with =
break x, so 90% of x is not a lot.</div><div><br></div><div>So the two are =
completely different things to me for that very important reason.</div><div=
>If a large number of people convince me that things are different on their=
code bases, I'd be surprised.</div><div>But it's not impossible I don't se=
e the worlds code bases.</div><div><br></div><div>But for me, unique_p=
tr seems to have definitely proved it's worth in replacing new. A lot of co=
de bases I've seen do benefit from it.</div><div>With goto to break x conve=
rsions, I imagine the code bases that would gain from the conversion would =
me orders of magnitude smaller.</div><div><br></div><div>This is the k=
ey measure of a feature's worth to me. If the goto / break x yielded e=
ven a fraction of as much actual conversion as new to unique_ptr, I'd =
be more excited by the feature. I suspect it won't, But that's why I wouldn=
't remotely compare the two and is the only metric on which I can see being=
convinced the two are remotely comparable for your analogy purpose.</div><=
div><br></div><div>Tat's why the conversion stat's of what break x has=
actually yielded for other language is of so much interest to me=
..</div><div><br></div><div>That's why I wouldn't remotely try to make the t=
ype of comparison you are promoting, I don't think it makes sense because I=
don't think the conversion results would be remotely comparable and if we =
had stats I think it would show that.</div><div><br></div><div>But I do app=
reciate other peoples experiences with their code bases might be radically =
different but without stats I think it's hard for anyone to argue credibly =
either way.</div><div><br></div><div>I don't see wild risk for introdu=
cing break x, I just think I'm not likely to use it that often and I'm conv=
inced that will be the use case for the majority of people by way far. If n=
ew features in C++ like constexpr make break x more necessary than that wou=
ld change my thinking.</div><div><br></div><div>But if it helps a few peopl=
e who write parsers though, I wouldn't object to it being added, but I=
'm mildly against. and see myself only changing to mildly for at best witho=
ut more evidence of the need. That every other language has the feature isn=
't compelling for me without stats of people actually using it.</div><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8=
ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-w=
idth: 1px; border-left-style: solid;">
<br>Likewise, `goto` can be used in ways which increase readability bu
<br>it's far too easy (especially for junior engineers) to use in ways
<br>that cause bugs or make code incomprehensible. The labeled-break
<br>feature is a way of allowing a goto-like construct that is much more
<br>limited and hence less dangerous (since you can't jump into the middle
<br>of unrelated scopes).
<br></blockquote><div><br></div><div>I never saw this problem, I wasn't tem=
pted to abuse goto myself when learning C++ and I didn't see it abused (muc=
h) in any code bases I worked on ever, certainly not in recent times, so I =
can't relate. I might have been lucky. But if that's what you see=
, I can't argue with your experience, but that was mine.</div><div><br></di=
v><div>I'll be interested in where the consensus arrives at for this featur=
e. From the sounds of people, the consensus for the feature might exist her=
e. How that translates elsewhere I don't know. I think the feature&nbs=
p;needs stats proof for me to get excited about it for other peop=
le, but it's not a risky feature so maybe that doesn't matter. If it g=
oes in and isn't used much, if there is no harm, so what, I guess.</div><di=
v><br></div><div>I'd be more excited about a more powerful yet brief switch=
if it could be done without making a mockery of things, but that seems way=
harder with way more risk.</div><div> </div><blockquote class=3D"gmai=
l_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: soli=
d;">--=20
<br>Sean Middleditch
<br><a onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F=
%2Fseanmiddleditch.com\46sa\75D\46sntz\0751\46usg\75AFQjCNHx3WLavT-kbToOv7I=
L4uvcN5l-vg';return true;" onclick=3D"this.href=3D'http://www.google.com/ur=
l?q\75http%3A%2F%2Fseanmiddleditch.com\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
x3WLavT-kbToOv7IL4uvcN5l-vg';return true;" href=3D"http://seanmiddleditch.c=
om" target=3D"_blank">http://seanmiddleditch.com</a>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3_504782852.1407193759600--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 5 Aug 2014 10:25:59 +0800
Raw View
On 2014-08-05, at 3:36 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> I don't see much risk in it. The cost is an interesting question; I can easily
> count six compilers and two static analysis tools from the usual committee
> attendees, and a handful more of both compilers and tools outside the
> usual attendees that need to cope. So, it's more a question of the
> benefit/cost ratio, and for this particular idea, that ratio seems low.
It should be simple to implement, though. Just take the code which searches for the enclosing switch/loop statement and have it inspect the labels (of the candidate statements) as it iterates outward.
Interestingly, labeled breaks are useful for such searches. The feature could be useful to implement itself.
--
---
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: Hyman Rosen <hyman.rosen@gmail.com>
Date: Tue, 5 Aug 2014 10:47:55 -0400
Raw View
--001a1137020a10953a04ffe2f234
Content-Type: text/plain; charset=UTF-8
@VV wrt Ada: In fact, yes. Ada is a brilliantly designed language,
arguably decades ahead of its time, and it still holds up today. If it
contains a feature, other languages would generally do well to imitate it.
On Mon, Aug 4, 2014 at 10:25 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014-08-05, at 3:36 AM, Ville Voutilainen <ville.voutilainen@gmail.com>
> wrote:
>
> > I don't see much risk in it. The cost is an interesting question; I can
> easily
> > count six compilers and two static analysis tools from the usual
> committee
> > attendees, and a handful more of both compilers and tools outside the
> > usual attendees that need to cope. So, it's more a question of the
> > benefit/cost ratio, and for this particular idea, that ratio seems low.
>
> It should be simple to implement, though. Just take the code which
> searches for the enclosing switch/loop statement and have it inspect the
> labels (of the candidate statements) as it iterates outward.
>
> Interestingly, labeled breaks are useful for such searches. The feature
> could be useful to implement itself.
>
> --
>
> ---
> 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/.
--001a1137020a10953a04ffe2f234
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">@VV wrt Ada: In fact, yes. =C2=A0Ada is a brilliantly desi=
gned language, arguably decades ahead of its time, and it still holds up to=
day. =C2=A0If it contains a feature, other languages would generally do wel=
l to imitate it.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Aug 4=
, 2014 at 10:25 PM, David Krauss <span dir=3D"ltr"><<a href=3D"mailto:po=
tswa@gmail.com" target=3D"_blank">potswa@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""><br>
On 2014-08-05, at 3:36 AM, Ville Voutilainen <<a href=3D"mailto:ville.vo=
utilainen@gmail.com">ville.voutilainen@gmail.com</a>> wrote:<br>
<br>
> I don't see much risk in it. The cost is an interesting question; =
I can easily<br>
> count six compilers and two static analysis tools from the usual commi=
ttee<br>
> attendees, and a handful more of both compilers and tools outside the<=
br>
> usual attendees that need to cope. So, it's more a question of the=
<br>
> benefit/cost ratio, and for this particular idea, that ratio seems low=
..<br>
<br>
</div>It should be simple to implement, though. Just take the code which se=
arches for the enclosing switch/loop statement and have it inspect the labe=
ls (of the candidate statements) as it iterates outward.<br>
<br>
Interestingly, labeled breaks are useful for such searches. The feature cou=
ld be useful to implement itself.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a1137020a10953a04ffe2f234--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 30 Sep 2014 17:44:43 -0400
Raw View
On 2014-08-02 02:02, Andrew Tomazos wrote:
> There was agreement from Dr S and EWG that this would have been a better
> design for switch, but it isn't worth having two versions in the language.
> So we just have to live with the crappy 1972 B version as patched by
> -Wimplicit-fallthrough and [fallthrough].
Has [[fallthrough]] been standardized and/or is there any active work to
do so?
--
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: Wed, 1 Oct 2014 01:12:45 +0300
Raw View
On 1 October 2014 00:44, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2014-08-02 02:02, Andrew Tomazos wrote:
>> There was agreement from Dr S and EWG that this would have been a better
>> design for switch, but it isn't worth having two versions in the language.
>> So we just have to live with the crappy 1972 B version as patched by
>> -Wimplicit-fallthrough and [fallthrough].
>
> Has [[fallthrough]] been standardized and/or is there any active work to
> do so?
1) No it hasn't. 2) I don't recall seeing recent proposals proposing that.
--
---
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: masse.nicolas@gmail.com
Date: Wed, 1 Oct 2014 13:57:44 -0700 (PDT)
Raw View
------=_Part_974_115392597.1412197064635
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Well, for me adding [[fallthrough]] can't be seen as a real solution. It is=
=20
for me just a workaround, nothing more and I don't like the idea of having=
=20
such an attribute.=20
For me, the previous proposal fails because they were way too ambitious.=20
The idea of adding a new "explicit switch" control structure was way too=20
bloated and could lead to potential misunderstanding.=20
Even the proposal of adding Java-style labeled break/continue is too big=20
for me. In that sense, I agree with what Bjarne said and about the fact=20
that we should be concerned about the clarity of our code. Anyway, this=20
does not mean that we should with the switch statement as he is now,=20
especially because he is not that clear either.=20
Basically the problem of knowing if a fallthrough in a case block is=20
intentionnal or not still remains, and relying on an attribute for that is=
=20
a fail for me.=20
So my solution is to add just the "goto case" (like in C#) statement,=20
nothing more.
Just note 2 things here:
- the fact that such a structure exists in C# is all but an argument. I put=
=20
it here so that some of you will probably get the idea faster.=20
- When I said nothing more, this really means NOTHING more. Current code=20
should still compile at this point had have the exact same behaviour as=20
before. This for sure include the falling-through specificity of c++'s=20
switch statement (backward compatibility is just too important to make=20
otherwise). This is also true for the variable visibility inside a switch=
=20
block. If someone wants to change that behaviour, then I believe this=20
should be another proposal by itself.=20
In the end, this just allows us to change this code:
switch (caseSwitch)
{
case x:
std::cout << "case x" << std::endl;
break;
case y:
std::cout << "case y" << std::endl;
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
into this:
switch (caseSwitch)
{
case x:
std::cout << "case x" << std::endl;
break;=20
case y:
std::cout << "case y" << std::endl;
goto case 3;=20
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
Benefits :
- the code is self explanatory and can be easilly read an understood.
- there is no ambiguity about the fact that falling through is intentionnal=
=20
or not anymore.
- the case blocks could be later be reordered that way:
switch (caseSwitch)
{
case y:
std::cout << "case y" << std::endl;
goto case z;=20
case x:
std::cout << "case x" << std::endl;
break;
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
The program will keep his behaviour.
Issues:
- Such a structure will allow several case block to fall into the same=20
block.=20
example:=20
switch (caseSwitch)
{
case x:
std::cout << "case x" << std::endl;
goto case z;=20
case y:
std::cout << "case y" << std::endl;
goto case z;=20
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
I don't know if this should be seen as an issue, but the fact is that it=20
wasn't possible before. So we should think about it. (can't this introduce=
=20
compiler issues?, won't this be over-used?, ...)
- What if we want to go into the default block? probably adding a "goto=20
default" statement should be part of the proposal.
- what about this :
switch (a_var)
{
case x:
std::cout << "case x" << std::endl;
break;
case y:
switch(another_var)
{
case x:
std::cout << "case x bis" << std::endl;
break;
case y:
goto case z;
}
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
or even this :
switch (a_var)
{
case x:
std::cout << "case x" << std::endl;
break;
case y:
switch(another_var)
{
case x:
std::cout << "case x bis" << std::endl;
break;
case y:
goto case z;
case z:
std::cout << "case z bis" << std::endl;
goto default;
}
case z:
std::cout << "case z" << std::endl;
break;
default:
std::cout << "default" << std::endl;
break;
}
What 's the correct behaviour of this code? Should all this be allowed?
- Should the abscence of a goto case or break statement inside a case bock=
=20
(causing a fallthrough then) result in a warning being emitted by the=20
compiler? Should it be the default behaviour? Note that this could lead=20
some code to fails to compile if warnings are treated as errors for=20
example. Also should such construct be considered as obsolete (even if=20
still valid?)
Well, I end up in writing quite some things. I hope that all that will help=
=20
to make that subject advance in the right direction.
Masse Nicolas.
Le mardi 30 septembre 2014 23:44:58 UTC+2, Matthew Woehlke a =C3=A9crit :
>
> On 2014-08-02 02:02, Andrew Tomazos wrote:=20
> > There was agreement from Dr S and EWG that this would have been a bette=
r=20
> > design for switch, but it isn't worth having two versions in the=20
> language.=20
> > So we just have to live with the crappy 1972 B version as patched by=
=20
> > -Wimplicit-fallthrough and [fallthrough].=20
>
> Has [[fallthrough]] been standardized and/or is there any active work to=
=20
> do so?=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_974_115392597.1412197064635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Well, for me adding [[fallthrough]] can't be seen as =
a real solution. It is for me just a workaround, nothing more and I don't l=
ike the idea of having such an attribute. <br></div><div>For me, the p=
revious proposal fails because they were way too ambitious. The idea of add=
ing a new "explicit switch" control structure was way too bloated and could=
lead to potential misunderstanding. </div><div>Even the proposal of a=
dding Java-style labeled break/continue is too big for me. In that sense, I=
agree with what Bjarne said and about the fact that we should be concerned=
about the clarity of our code. Anyway, this does not mean that we should w=
ith the switch statement as he is now, especially because he is not that cl=
ear either. </div><div>Basically the problem of knowing if a fallthrou=
gh in a case block is intentionnal or not still remains, and relying on an =
attribute for that is a fail for me. </div><div>So my solution is to add ju=
st the "goto case" (like in C#) statement, nothing more.</div><div>Just not=
e 2 things here:</div><div>- the fact that such a structure exists in C# is=
all but an argument. I put it here so that some of you will probably get t=
he idea faster. </div><div>- When I said nothing more, this really mea=
ns NOTHING more. Current code should still compile at this point had have t=
he exact same behaviour as before. This for sure include the falling-throug=
h specificity of c++'s switch statement (backward compatibility is ju=
st too important to make otherwise). This is also true for the variable vis=
ibility inside a switch block. If someone wants to change that behaviour, t=
hen I believe this should be another proposal by itself. </div><div><b=
r></div><div><br></div><div>In the end, this just allows us to change this =
code:</div><div><div style=3D"background-color: #FAFAFA; border-color: #BBB=
; border-style: solid; border-width: 1px; word-wrap: break-word;" class=3D"=
prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">switch</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">caseSwitch</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> x</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; std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"case=
x"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">endl</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 st=
yle=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=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"case y"</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
ndl</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</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"case z"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">break</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br> </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">default</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> std</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify">"default"</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">bre=
ak</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></=
div><br>into this:</div><div><div style=3D"background-color: #FAFAFA; borde=
r-color: #BBB; border-style: solid; border-width: 1px; word-wrap: break-wor=
d;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpret=
typrint"><span style=3D"color: #008;" class=3D"styled-by-prettify">switch</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">caseSwitch</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">case</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><<</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-=
prettify">"case x"</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> st=
d</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">endl</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">break</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> <br> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">case</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #080;" class=3D"styled-by-prettify">"case y"</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">endl</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"s=
tyled-by-prettify">goto</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><sp=
an 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">case</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #080;" class=3D"styled-by-prettify">"case z"</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">endl</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">break</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">default</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify"=
>"default"</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">endl</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">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:=
#660;" class=3D"styled-by-prettify">}</span></div></code></div><br></div><=
div>Benefits :</div><div>- the code is self explanatory and can be easilly =
read an understood.</div><div>- there is no ambiguity about the fact that f=
alling through is intentionnal or not anymore.</div><div>- the case blocks =
could be later be reordered that way:</div><div><div style=3D"background-co=
lor: #FAFAFA; border-color: #BBB; border-style: solid; border-width: 1px; w=
ord-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">switch</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">caseSwitch<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"case y"</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
ndl</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-pret=
tify">goto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">case</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</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"styled-by-prettify"> x</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">"case x"</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><<</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">endl</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">break</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"> =
z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
out </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><&l=
t;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">"case z"</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">break</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: #0=
08;" class=3D"styled-by-prettify">default</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> std</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" clas=
s=3D"styled-by-prettify">"default"</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
ndl</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-pret=
tify">break</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div>=
</code></div>The program will keep his behaviour.<br></div><div><br></div><=
div>Issues:</div><div>- Such a structure will allow several case block to f=
all into the same block. </div><div>example: </div><div><div styl=
e=3D"background-color: #FAFAFA; border-color: #BBB; border-style: solid; bo=
rder-width: 1px; word-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">switch</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">caseSwitch</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">)</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</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"case x"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">goto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> z</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</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"> y</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; std</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #080;" class=3D"styled-by-prettify">"case y"</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">goto</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> z</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"styled-by-pretti=
fy"> z</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; std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"case z"</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">endl</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">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">default</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"default"</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
endl</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-pre=
ttify">break</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div=
></code></div>I don't know if this should be seen as an issue, but the fact=
is that it wasn't possible before. So we should think about it. (can't thi=
s introduce compiler issues?, won't this be over-used?, ...)<br></div><div>=
- What if we want to go into the default block? probably adding a "goto def=
ault" statement should be part of the proposal.</div><div>- what about this=
:</div><div><div style=3D"background-color: #FAFAFA; border-color: #BBB; b=
order-style: solid; border-width: 1px; word-wrap: break-word;" class=3D"pre=
ttyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">switch</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">a_var</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">case</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> x</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; std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #080;" class=3D"styled-by-prettify">"case x"</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><<</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=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"> y</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: #0=
08;" 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">another_var</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br> </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: #008;" class=3D"styled-by-prettify">case</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> x</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> &n=
bsp; std</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">cout </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;<</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #080;" class=3D"styled-by-prettify">"case x bis"=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">break</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">goto</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">case</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> z</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: #660;" class=3D"s=
tyled-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">case</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> z</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"case=
z"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">endl</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 sty=
le=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: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">default</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br> std</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080=
;" class=3D"styled-by-prettify">"default"</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">endl</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">break</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></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span></div></code></div>or even this :<br></div><div><div style=3D"backgrou=
nd-color: #FAFAFA; border-color: #BBB; border-style: solid; border-width: 1=
px; word-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">switch</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">a_var<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">case</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"case x"</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">e=
ndl</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-pret=
tify">break</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
case</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y</sp=
an><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">s=
witch</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">another_var</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </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;" cl=
ass=3D"styled-by-prettify">case</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" cla=
ss=3D"styled-by-prettify">"case x bis"</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><<</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">endl</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">break</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-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"> y</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">go=
to</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">case</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> z</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">case=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> &n=
bsp; std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">cout </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #080;" class=3D"styled-by-prettify">"case =
z bis"</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">g=
oto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">default</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; </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">case</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> z</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp;std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><<</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">"case z"</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">endl</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">break</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">default</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br> std</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">cout </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">"default"</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify"><<</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">endl</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">brea=
k</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 s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></d=
iv>What 's the correct behaviour of this code? Should all this be allowed?<=
/div><div>- Should the abscence of a goto case or break statement inside a =
case bock (causing a fallthrough then) result in a warning being emitted by=
the compiler? Should it be the default behaviour? Note that this could lea=
d some code to fails to compile if warnings are treated as errors for examp=
le. Also should such construct be considered as obsolete (even if still val=
id?)</div><div><br></div><div>Well, I end up in writing quite some things. =
I hope that all that will help to make that subject advance in the right di=
rection.</div><div><br></div><div>Masse Nicolas.</div><div><br></div><br>Le=
mardi 30 septembre 2014 23:44:58 UTC+2, Matthew Woehlke a =C3=A9crit =
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On 2014-08-02 02:02, Andrew T=
omazos wrote:
<br>> There was agreement from Dr S and EWG that this would have been a =
better
<br>> design for switch, but it isn't worth having two versions in the l=
anguage.
<br>> So we just have to live with the crappy 1972 B version as pa=
tched by
<br>> -Wimplicit-fallthrough and [fallthrough].
<br>
<br>Has [[fallthrough]] been standardized and/or is there any active work t=
o
<br>do so?
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_974_115392597.1412197064635--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 01 Oct 2014 17:16:58 -0400
Raw View
On 2014-10-01 16:57, masse.nicolas@gmail.com wrote:
> [tl;dq I want 'goto case' instead]
>
> Issues:
> - Such a structure will allow several case block to fall into the same
> block.
> example:
> switch (caseSwitch)
> {
> case x:
> std::cout << "case x" << std::endl;
> goto case z;
> case y:
> std::cout << "case y" << std::endl;
> goto case z;
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
I'd actually consider that an advantage. I know I've run into situations
before where I had this sort of overlapping logic, though I'm not 100%
sure if this would have helped, or if it was a case of needing to do
some shared logic first and then further differentiate. This would only
help the first case, but that's still something.
I'll admit, I share some degree of 'goto phobia'. 'continue case' might
be more palatable. Otherwise I'm fairly agnostic to any lightweight (I
didn't like 'explicit switch' either) solution that allows the compiler
to diagnose accidental fallthrough, i.e. I'd be happy with either solution.
That said... benefits of [[fallthrough]]:
- Already implemented by at least one compiler (clang).
- Very conducive to being wrapped in a macro so code can still build on
legacy compilers.
The second is more an issue when making use of the ability to jump
around in a switch, although there is still the tiny cost of having to
repeat the next case label.
> - what about this :
> switch (a_var)
> {
> case x:
> std::cout << "case x" << std::endl;
> break;
> case y:
> switch(another_var)
> {
> case x:
> std::cout << "case x bis" << std::endl;
> break;
> case y:
> goto case z;
> }
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
This makes no sense. I assume the point was to ask if you can jump from
an inner switch to an outer switch (my knee-jerk reaction is "no"), but
what you've actually written contains an implicit fall-through. Maybe
you meant to have a 'break;' after the inner switch?
--
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: masse.nicolas@gmail.com
Date: Wed, 1 Oct 2014 14:53:58 -0700 (PDT)
Raw View
------=_Part_6371_1346898627.1412200438655
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Le mercredi 1 octobre 2014 23:17:19 UTC+2, Matthew Woehlke a =C3=A9crit :
>
> On 2014-10-01 16:57, masse....@gmail.com <javascript:> wrote:=20
> > [tl;dq I want 'goto case' instead]=20
> >=20
>
> > - what about this :=20
> > switch (a_var)=20
> > {=20
> > case x:=20
> > std::cout << "case x" << std::endl;=20
> > break;=20
> > case y:=20
> > switch(another_var)=20
> > {=20
> > case x:=20
> > std::cout << "case x bis" << std::endl;=20
> > break;=20
> > case y:=20
> > goto case z;=20
> > }=20
> > case z:=20
> > std::cout << "case z" << std::endl;=20
> > break;=20
> > default:=20
> > std::cout << "default" << std::endl;=20
> > break;=20
> > }=20
>
> This makes no sense. I assume the point was to ask if you can jump from=
=20
> an inner switch to an outer switch (my knee-jerk reaction is "no"), but=
=20
> what you've actually written contains an implicit fall-through. Maybe=20
> you meant to have a 'break;' after the inner switch?=20
>
> --=20
> Matthew=20
>
In fact the implicit fallthrough here was inserted by accident. But when I=
=20
saw that I decide to let it that way since, in the end, this can still be=
=20
considered as legal code :-).
But yes, the idea at the beginning was about switching from an inner switch=
=20
into an outer one. And i do believe that this should be allowed, since this=
=20
could also be done through if-else statement.=20
=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an 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_6371_1346898627.1412200438655
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>Le mercredi 1 octobre 2014 23:17:19 UTC+2, Matthew=
Woehlke a =C3=A9crit :<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On=
2014-10-01 16:57, <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"tGl6VxY1oVwJ" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">masse....@gmail.com=
</a> wrote:
<br>> [tl;dq I want 'goto case' instead]
<br>>=20
<br><br>> - what about this :
<br>> switch (a_var)
<br>> {
<br>> case x:
<br>> std::cout << "case x" << s=
td::endl;
<br>> break;
<br>> case y:
<br>> switch(another_var)
<br>> {
<br>> case x:
<br>> std::cout <<=
; "case x bis" << std::endl;
<br>> break;
<br>> case y:
<br>> goto case z;
<br>> }
<br>> case z:
<br>> std::cout << "case z" << st=
d::endl;
<br>> break;
<br>> default:
<br>> std::cout << "default" << =
std::endl;
<br>> break;
<br>> }
<br>
<br>This makes no sense. I assume the point was to ask if you can jump from
<br>an inner switch to an outer switch (my knee-jerk reaction is "no"), but
<br>what you've actually written contains an implicit fall-through. Maybe
<br>you meant to have a 'break;' after the inner switch?
<br>
<br>--=20
<br>Matthew
<br></blockquote><div><br></div><div>In fact the implicit fallthrough here =
was inserted by accident. But when I saw that I decide to let it that way s=
ince, in the end, this can still be considered as legal code :-).</div><div=
>But yes, the idea at the beginning was about switching from an inner switc=
h into an outer one. And i do believe that this should be allowed, since th=
is could also be done through if-else statement. </div><div><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6371_1346898627.1412200438655--
.
Author: ron novy <rsn10100@gmail.com>
Date: Wed, 1 Oct 2014 17:05:13 -0700 (PDT)
Raw View
------=_Part_6177_761239319.1412208313610
Content-Type: text/plain; charset=UTF-8
I like the idea, but I can see a few problems immediately. When using
break label or continue label you are basically saying "goto
label_block_end" or "goto label_block_end", so it is basically the same as
a goto statement to the compiler. By using any type of 'goto' statement,
you introduce the possibility of ambiguity and uncertainty into the code
where an object may exist in some cases but not others. An object may
exist and have it's constructor called, but not have it's destructor called
when it goes out of scope. Or the opposite can happen where an objects
constructor was never called but it's destructor gets called. In Java this
can happen all the time (and it's said to be 'ok' even though it is not)
because the fact that Java has garbage collection that can handle the leaks
in the first case. C++ has no garbage collection and it's very likely that
it never will. The idea that garbage collection will save you when you
make a mistake is false and that idea only encourages features that
encourage bad coding practices.
Another reason *not* to use break label, continue label and goto is where
the optimizer will simply rule the code to be too complex because of all
the ambiguous jumps and 'give up'.
So my problem with this isn't necessarily with the idea of making that
feature available, it's with the fact that it can encourage the programmer
to write bad code that is ambiguous, introduces uncertainty and is possibly
creating many many bugs.
"Don't help the compiler." <- That should say it all. If you can't write
the algorithm without the goto statement, then re-think your approach.
Even if you have to duplicate some code, the optimizer will thank you and
you will be thankful for that optimizer.
I know there are completely valid use cases for this feature, but I think
*not* having it will prevent a lot of really bad things. I could have it
completely wrong and I could have missed the mark, but that's my two
cents...
--
---
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_6177_761239319.1412208313610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I like the idea, but I can see a few problems immediately.=
When using break label or continue label you are basically saying "g=
oto label_block_end" or "goto label_block_end", so it is basically the same=
as a goto statement to the compiler. By using any type of 'goto' sta=
tement, you introduce the possibility of ambiguity and uncertainty into the=
code where an object may exist in some cases but not others. An obje=
ct may exist and have it's constructor called, but not have it's destructor=
called when it goes out of scope. Or the opposite can happen where an obje=
cts constructor was never called but it's destructor gets called. In =
Java this can happen all the time (and it's said to be 'ok' even though it =
is not) because the fact that Java has garbage collection that can handle t=
he leaks in the first case. C++ has no garbage collection and it's ve=
ry likely that it never will. The idea that garbage collection will s=
ave you when you make a mistake is false and that idea only encourages feat=
ures that encourage bad coding practices.<div><br></div><div>Another reason=
*not* to use break label, continue label and goto is where the optimizer w=
ill simply rule the code to be too complex because of all the ambiguous jum=
ps and 'give up'.<div><br></div><div><div><span style=3D"color: rgb(0, 0, 0=
); font-family: arial, sans-serif; font-size: small;">So my problem with th=
is isn't necessarily with the idea of making that feature available, it's w=
ith the fact that it can encourage the programmer to write bad code that&nb=
sp;</span><span style=3D"color: rgb(0, 0, 0); font-family: arial, sans-seri=
f; font-size: small;">is ambiguous,</span><span style=3D"color: rgb(0, 0, 0=
); font-family: arial, sans-serif; font-size: small;"> </span><span st=
yle=3D"color: rgb(0, 0, 0); font-family: arial, sans-serif; font-size: smal=
l;">introduces uncertainty and is possibly creating many many bugs.</span><=
/div></div><div><span class=3D"styled-by-prettify"><div><font style=3D"back=
ground-color: rgb(255, 255, 255);" color=3D"#000000" face=3D"arial, sans-se=
rif" size=3D"2"><br></font></div><div><font style=3D"background-color: rgb(=
255, 255, 255);" color=3D"#000000" face=3D"arial, sans-serif" size=3D"2">"D=
on't help the compiler." <- That should say it all. If you can't w=
rite the algorithm without the goto statement, then re-think your appr=
oach. Even if you have to duplicate some code, the optimizer will tha=
nk you and you will be thankful for that optimizer.</font></div><div><font =
style=3D"background-color: rgb(255, 255, 255);" color=3D"#000000" face=3D"a=
rial, sans-serif" size=3D"2"><br></font></div><div>I know there are complet=
ely valid use cases for this feature, but I think <i>not</i> having it=
will prevent a lot of really bad things. I could have it completely =
wrong and I could have missed the mark, but that's my two cents...</div></s=
pan></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_6177_761239319.1412208313610--
.
Author: ron novy <rsn10100@gmail.com>
Date: Wed, 1 Oct 2014 17:12:18 -0700 (PDT)
Raw View
------=_Part_6154_756554500.1412208738933
Content-Type: text/plain; charset=UTF-8
** "goto label_block_end" or "goto label_block_start"
--
---
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_6154_756554500.1412208738933
Content-Type: text/html; charset=UTF-8
<div dir="ltr">** "goto label_block_end" or "goto label_block_start"</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_6154_756554500.1412208738933--
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 2 Oct 2014 08:26:20 +0800
Raw View
--Apple-Mail=_6225BC6E-13D6-48B2-8565-FCB1F2381509
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-02, at 8:05 AM, ron novy <rsn10100@gmail.com> wrote:
> When using break label or continue label you are basically saying "goto l=
abel_block_end" or "goto label_block_end", so it is basically the same as a=
goto statement to the compiler. =20
So are for and while.
> By using any type of 'goto' statement, you introduce the possibility of a=
mbiguity and uncertainty into the code where an object may exist in some ca=
ses but not others. An object may exist and have it's constructor called, =
but not have it's destructor called when it goes out of scope.
Not in C++. All branching statements including goto respect the object mode=
l.
> Another reason *not* to use break label, continue label and goto is where=
the optimizer will simply rule the code to be too complex because of all t=
he ambiguous jumps and 'give up'.
You have no idea what you're talking about.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_6225BC6E-13D6-48B2-8565-FCB1F2381509
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10–02, at 8:05 AM, ron novy <<a href=3D"mailto:rsn10100@gmai=
l.com">rsn10100@gmail.com</a>> wrote:</div><br class=3D"Apple-interchang=
e-newline"><blockquote type=3D"cite"><span style=3D"font-family: Helvetica;=
font-size: 12px; font-style: normal; font-variant: normal; font-weight: no=
rmal; letter-spacing: normal; line-height: normal; orphans: auto; text-alig=
n: start; text-indent: 0px; text-transform: none; white-space: normal; wido=
ws: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; d=
isplay: inline !important;">When using break label or continue label you ar=
e basically saying "goto label_block_end" or "goto label_block_end", so it =
is basically the same as a goto statement to the compiler. </span></b=
lockquote><div><br></div><div>So are <font face=3D"Courier">for</font> and =
<font face=3D"Courier">while</font>.</div><br><blockquote type=3D"cite"><sp=
an style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px; float: none; display: inline !important;">By using any=
type of 'goto' statement, you introduce the possibility of ambiguity and u=
ncertainty into the code where an object may exist in some cases but not ot=
hers. An object may exist and have it's constructor called, but not h=
ave it's destructor called when it goes out of scope.</span></blockquote></=
div><br><div>Not in C++. All branching statements including <font face=3D"C=
ourier">goto</font> respect the object model.</div><div><br></div><div><blo=
ckquote type=3D"cite">Another reason *not* to use break label, continue lab=
el and goto is where the optimizer will simply rule the code to be too comp=
lex because of all the ambiguous jumps and 'give up'.<br class=3D"Apple-int=
erchange-newline"></blockquote></div><div><br></div><div>You have no idea w=
hat you’re talking about.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_6225BC6E-13D6-48B2-8565-FCB1F2381509--
.
Author: ron novy <rsn10100@gmail.com>
Date: Wed, 1 Oct 2014 17:57:37 -0700 (PDT)
Raw View
------=_Part_6578_403121901.1412211457525
Content-Type: text/plain; charset=UTF-8
David, you're correct. I'm thinking of a complex code example that makes
no sense. I started with switch and for loops and created what I thought
was valid code, but I'm certain now that it won't even compile...
--
---
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_6578_403121901.1412211457525
Content-Type: text/html; charset=UTF-8
<div dir="ltr">David, you're correct. I'm thinking of a complex code example that makes no sense. I started with switch and for loops and created what I thought was valid code, but I'm certain now that it won't even compile...</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
------=_Part_6578_403121901.1412211457525--
.
Author: Myriachan <myriachan@gmail.com>
Date: Wed, 1 Oct 2014 22:40:38 -0700 (PDT)
Raw View
------=_Part_1934_1943898417.1412228438925
Content-Type: text/plain; charset=UTF-8
This "goto case X" command seems far more limited in use than "break label"
and "continue label". It can't easily be used to break out of nested "for"
loops, for example. Is it really worth changing the language this much for
a more limited use?
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1934_1943898417.1412228438925
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>This "goto case X" command seems far more limited in =
use than "break label" and "continue label". It can't easily be used =
to break out of nested "for" loops, for example. Is it really worth c=
hanging the language this much for a more limited use?<br><br>Melissa<br></=
div><br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1934_1943898417.1412228438925--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Thu, 2 Oct 2014 04:08:25 -0700 (PDT)
Raw View
------=_Part_247_948527669.1412248105421
Content-Type: text/plain; charset=UTF-8
On Wednesday, 1 October 2014 21:57:44 UTC+1, masse....@gmail.com wrote:
>
> Benefits :
> - the code is self explanatory and can be easilly read an understood.
> - there is no ambiguity about the fact that falling through is
> intentionnal or not anymore.
> - the case blocks could be later be reordered that way:
> switch (caseSwitch)
> {
> case y:
> std::cout << "case y" << std::endl;
> goto case z;
> case x:
> std::cout << "case x" << std::endl;
> break;
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
> The program will keep his behaviour.
>
> Issues:
> - Such a structure will allow several case block to fall into the same
> block.
> example:
> switch (caseSwitch)
> {
> case x:
> std::cout << "case x" << std::endl;
> goto case z;
> case y:
> std::cout << "case y" << std::endl;
> goto case z;
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
> I don't know if this should be seen as an issue, but the fact is that it
> wasn't possible before. So we should think about it. (can't this introduce
> compiler issues?, won't this be over-used?, ...)
> - What if we want to go into the default block? probably adding a "goto
> default" statement should be part of the proposal.
> - what about this :
> switch (a_var)
> {
> case x:
> std::cout << "case x" << std::endl;
> break;
> case y:
> switch(another_var)
> {
> case x:
> std::cout << "case x bis" << std::endl;
> break;
> case y:
> goto case z;
> }
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
> or even this :
> switch (a_var)
> {
> case x:
> std::cout << "case x" << std::endl;
> break;
> case y:
> switch(another_var)
> {
> case x:
> std::cout << "case x bis" << std::endl;
> break;
> case y:
> goto case z;
> case z:
> std<span
> switch (caseSwitch)
> {
> case x:
> std::cout << "case x" << std::endl;
> break;
> case y:
> std::cout << "case y" << std::endl;
> goto case 3;
> case z:
> std::cout << "case z" << std::endl;
> break;
> default:
> std::cout << "default" << std::endl;
> break;
> }
>
>
Do you mean goto case 3?
I notice in all the examples you gave, the goto case instructions were
forward gotos. Was that intentional or not?
> .
>
--
---
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_247_948527669.1412248105421
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><BR>On Wednesday, 1 October 2014 21:57:44 UTC+1, masse....=
@gmail.com wrote:=20
<DIV> </DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV dir=3Dltr>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid"><CODE>
<DIV><BR></DIV>
<DIV>Benefits :</DIV>
<DIV>- the code is self explanatory and can be easilly read an understood.<=
/DIV>
<DIV>- there is no ambiguity about the fact that falling through is intenti=
onnal or not anymore.</DIV>
<DIV>- the case blocks could be later be reordered that way:</DIV>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid"><CODE>
<DIV><SPAN style=3D"COLOR: #008">switch</SPAN><SPAN style=3D"COLOR: #000"> =
</SPAN><SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">case=
Switch</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN sty=
le=3D"COLOR: #000"> y</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=
=3D"COLOR: #000"><BR> std</SPAN><SPAN style=3D"C=
OLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D=
"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN styl=
e=3D"COLOR: #080">"case y"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN =
style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN=
><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPA=
N><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> =
; </SPAN><SPAN style=3D"COLOR: #008">goto</SPAN><SPAN =
style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN =
style=3D"COLOR: #000"> z</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN st=
yle=3D"COLOR: #000"> <BR> </SPAN><SPAN style=3D"COLOR: #008">c=
ase</SPAN><SPAN style=3D"COLOR: #000"> x</SPAN><SPAN style=3D"COLOR: #660">=
:</SPAN><SPAN style=3D"COLOR: #000"><BR> std</SP=
AN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </=
SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"=
> </SPAN><SPAN style=3D"COLOR: #080">"case x"</SPAN><SPAN style=3D"COLOR: #=
000"> </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLO=
R: #000"> std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COL=
OR: #000">endl</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COL=
OR: #000"><BR> </SPAN><SPAN style=3D"COLOR: #008=
">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #00=
0"><BR> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN st=
yle=3D"COLOR: #000"> z</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN styl=
e=3D"COLOR: #000"><BR> std</SPAN><SPAN style=3D"=
COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=
=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN s=
tyle=3D"COLOR: #080">"case z"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SP=
AN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</S=
PAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</=
SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR>&n=
bsp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><S=
PAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &n=
bsp; </SPAN><SPAN style=3D"COLOR: #008">default</SPAN><SPAN style=3D"COLOR:=
#660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> =
std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">=
cout </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR=
: #000"> </SPAN><SPAN style=3D"COLOR: #080">"default"</SPAN><SPAN style=3D"=
COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=
=3D"COLOR: #000"> std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN styl=
e=3D"COLOR: #000">endl</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN styl=
e=3D"COLOR: #000"><BR> </SPAN><SPAN style=3D"COL=
OR: #008">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"CO=
LOR: #000"><BR></SPAN><SPAN style=3D"COLOR: #660">}</SPAN></DIV></CODE></DI=
V>The program will keep his behaviour.<BR></DIV>
<DIV><BR></DIV>
<DIV>Issues:</DIV>
<DIV>- Such a structure will allow several case block to fall into the same=
block. </DIV>
<DIV>example: </DIV>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid"><CODE>
<DIV><SPAN style=3D"COLOR: #008">switch</SPAN><SPAN style=3D"COLOR: #000"> =
</SPAN><SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">case=
Switch</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN sty=
le=3D"COLOR: #000"> x</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=
=3D"COLOR: #000"><BR> std</SPAN><SPAN style=3D"C=
OLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D=
"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN styl=
e=3D"COLOR: #080">"case x"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN =
style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN=
><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPA=
N><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> =
; </SPAN><SPAN style=3D"COLOR: #008">goto</SPAN><SPAN =
style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN =
style=3D"COLOR: #000"> z</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN st=
yle=3D"COLOR: #000"> <BR> </SPAN><SPAN style=3D"COLOR: #008">c=
ase</SPAN><SPAN style=3D"COLOR: #000"> y</SPAN><SPAN style=3D"COLOR: #660">=
:</SPAN><SPAN style=3D"COLOR: #000"><BR> std</SP=
AN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </=
SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"=
> </SPAN><SPAN style=3D"COLOR: #080">"case y"</SPAN><SPAN style=3D"COLOR: #=
000"> </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLO=
R: #000"> std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COL=
OR: #000">endl</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COL=
OR: #000"><BR> </SPAN><SPAN style=3D"COLOR: #008=
">goto</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #008=
">case</SPAN><SPAN style=3D"COLOR: #000"> z</SPAN><SPAN style=3D"COLOR: #66=
0">;</SPAN><SPAN style=3D"COLOR: #000"> <BR> </SPAN><SPAN styl=
e=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> z</SPAN><SPAN sty=
le=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> &n=
bsp; std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"C=
OLOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN st=
yle=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #080">"case z"</SPAN><SPA=
N style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN>=
<SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN=
><SPAN style=3D"COLOR: #000">endl</SPAN><SPAN style=3D"COLOR: #660">;</SPAN=
><SPAN style=3D"COLOR: #000"><BR> </SPAN><SPAN s=
tyle=3D"COLOR: #008">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN =
style=3D"COLOR: #000"><BR> </SPAN><SPAN style=3D"COLOR: #008">=
default</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #00=
0"><BR> std</SPAN><SPAN style=3D"COLOR: #660">::=
</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660">=
<<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #0=
80">"default"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLO=
R: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=
=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SPAN styl=
e=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN style=3D"CO=
LOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR></SPAN><SPAN style=3D"CO=
LOR: #660">}</SPAN></DIV></CODE></DIV>I don't know if this should be seen a=
s an issue, but the fact is that it wasn't possible before. So we should th=
ink about it. (can't this introduce compiler issues?, won't this be over-us=
ed?, ...)<BR></DIV>
<DIV>- What if we want to go into the default block? probably adding a "got=
o default" statement should be part of the proposal.</DIV>
<DIV>- what about this :</DIV>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid"><CODE>
<DIV><SPAN style=3D"COLOR: #008">switch</SPAN><SPAN style=3D"COLOR: #000"> =
</SPAN><SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">a_va=
r</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN style=3D=
"COLOR: #000"> x</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"C=
OLOR: #000"><BR> std</SPAN><SPAN style=3D"COLOR:=
#660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLO=
R: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"=
COLOR: #080">"case x"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=
=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPA=
N style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SP=
AN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN styl=
e=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> </S=
PAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> y</=
SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR>&n=
bsp; </SPAN><SPAN style=3D"COLOR: #008">switch</SPAN><=
SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">another_var<=
/SPAN><SPAN style=3D"COLOR: #660">)</SPAN><SPAN style=3D"COLOR: #000"><BR>&=
nbsp; </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"> x</SPA=
N><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> =
; std</SPAN><SPAN style=3D"COLOR:=
#660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLO=
R: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"=
COLOR: #080">"case x bis"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN s=
tyle=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN>=
<SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN=
><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> =
</SPAN><SPAN style=3D"COLOR: #00=
8">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #0=
00"><BR> </SPAN><SPAN style=3D"COL=
OR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> y</SPAN><SPAN style=3D"CO=
LOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">goto</SPAN><SPA=
N style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPA=
N style=3D"COLOR: #000"> z</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> z</SPAN=
><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> =
std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN s=
tyle=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN=
><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #080">"case z"</=
SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #660"><&l=
t;</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=3D"COLOR: #660"=
>::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SPAN style=3D"COLOR: #660=
">;</SPAN><SPAN style=3D"COLOR: #000"><BR> </SPAN=
><SPAN style=3D"COLOR: #008">break</SPAN><SPAN style=3D"COLOR: #660">;</SPA=
N><SPAN style=3D"COLOR: #000"><BR> </SPAN><SPAN style=3D"COLOR=
: #008">default</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"CO=
LOR: #000"><BR> std</SPAN><SPAN style=3D"COLOR: =
#660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLOR=
: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"C=
OLOR: #080">"default"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=
=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPA=
N style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SP=
AN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN styl=
e=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR></SPAN><SPAN styl=
e=3D"COLOR: #660">}</SPAN></DIV></CODE></DIV>or even this :<BR></DIV>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid"><CODE>
<DIV><SPAN style=3D"COLOR: #008">switch</SPAN><SPAN style=3D"COLOR: #000"> =
</SPAN><SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">a_va=
r</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN style=3D=
"COLOR: #000"> x</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"C=
OLOR: #000"><BR> std</SPAN><SPAN style=3D"COLOR:=
#660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLO=
R: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"=
COLOR: #080">"case x"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=
=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPA=
N style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SP=
AN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN styl=
e=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> </S=
PAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> y</=
SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR>&n=
bsp; </SPAN><SPAN style=3D"COLOR: #008">switch</SPAN><=
SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">another_var<=
/SPAN><SPAN style=3D"COLOR: #660">)</SPAN><SPAN style=3D"COLOR: #000"><BR>&=
nbsp; </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"> x</SPA=
N><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> =
; std</SPAN><SPAN style=3D"COLOR:=
#660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLO=
R: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"=
COLOR: #080">"case x bis"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN s=
tyle=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN>=
<SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN=
><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> =
</SPAN><SPAN style=3D"COLOR: #00=
8">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #0=
00"><BR> </SPAN><SPAN style=3D"COL=
OR: #008">case</SPAN><SPAN style=3D"COLOR: #000"> y</SPAN><SPAN style=3D"CO=
LOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">goto</SPAN><SPA=
N style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPA=
N style=3D"COLOR: #000"> z</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"> z</SPAN=
><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> =
std</SPAN><span</DIV></CODE></=
DIV></DIV></CODE></DIV></DIV><CODE>
<DIV>
<DIV style=3D"BORDER-BOTTOM: #bbb 1px solid; BORDER-LEFT: #bbb 1px solid; B=
ACKGROUND-COLOR: #fafafa; WORD-WRAP: break-word; BORDER-TOP: #bbb 1px solid=
; BORDER-RIGHT: #bbb 1px solid">
<DIV><SPAN style=3D"COLOR: #008">switch</SPAN><SPAN style=3D"COLOR: #000"> =
</SPAN><SPAN style=3D"COLOR: #660">(</SPAN><SPAN style=3D"COLOR: #000">case=
Switch</SPAN><SPAN 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 style=3D"COLOR: #008">case</SPAN><SPAN sty=
le=3D"COLOR: #000"> x</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=
=3D"COLOR: #000"><BR> std</SPAN><SPAN style=3D"C=
OLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D=
"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN styl=
e=3D"COLOR: #080">"case x"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN =
style=3D"COLOR: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN=
><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPA=
N><SPAN style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> =
; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN=
style=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"> <BR> &nbs=
p; </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #000=
"> y</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000">=
<BR> std</SPAN><SPAN style=3D"COLOR: #660">::</S=
PAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660"><=
;<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #080"=
>"case y"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #=
660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=3D"C=
OLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SPAN style=3D"=
COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &=
nbsp; </SPAN><SPAN style=3D"COLOR: #008">goto</SPAN><SPAN style=3D"COLOR: #=
000"> </SPAN><SPAN style=3D"COLOR: #008">case</SPAN><SPAN style=3D"COLOR: #=
000"> </SPAN><SPAN style=3D"COLOR: #066">3</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"> z</SPAN><SPAN styl=
e=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN><SPAN style=3D"CO=
LOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><SPAN sty=
le=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #080">"case z"</SPAN><SPAN=
style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #660"><<</SPAN><=
SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=3D"COLOR: #660">::</SPAN>=
<SPAN style=3D"COLOR: #000">endl</SPAN><SPAN style=3D"COLOR: #660">;</SPAN>=
<SPAN style=3D"COLOR: #000"><BR> </SPAN><SPAN st=
yle=3D"COLOR: #008">break</SPAN><SPAN style=3D"COLOR: #660">;</SPAN><SPAN s=
tyle=3D"COLOR: #000"><BR> </SPAN><SPAN style=3D"COLOR: #008">d=
efault</SPAN><SPAN style=3D"COLOR: #660">:</SPAN><SPAN style=3D"COLOR: #000=
"><BR> std</SPAN><SPAN style=3D"COLOR: #660">::<=
/SPAN><SPAN style=3D"COLOR: #000">cout </SPAN><SPAN style=3D"COLOR: #660">&=
lt;<</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR: #08=
0">"default"</SPAN><SPAN style=3D"COLOR: #000"> </SPAN><SPAN style=3D"COLOR=
: #660"><<</SPAN><SPAN style=3D"COLOR: #000"> std</SPAN><SPAN style=
=3D"COLOR: #660">::</SPAN><SPAN style=3D"COLOR: #000">endl</SPAN><SPAN styl=
e=3D"COLOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR> &nb=
sp; </SPAN><SPAN style=3D"COLOR: #008">break</SPAN><SPAN style=3D"CO=
LOR: #660">;</SPAN><SPAN style=3D"COLOR: #000"><BR></SPAN><SPAN style=3D"CO=
LOR: #660">}</SPAN></DIV></CODE></DIV></DIV></DIV>
<DIV> </DIV></BLOCKQUOTE>
<DIV>Do you mean goto case 3?</DIV>
<DIV> </DIV>
<DIV>I notice in all the examples you gave, the goto case instructions were=
forward gotos. Was that intentional or not?</DIV>
<BLOCKQUOTE style=3D"BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex=
; PADDING-LEFT: 1ex" class=3Dgmail_quote>
<DIV>.</DIV></BLOCKQUOTE></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_247_948527669.1412248105421--
.
Author: masse.nicolas@gmail.com
Date: Thu, 2 Oct 2014 04:49:09 -0700 (PDT)
Raw View
------=_Part_7169_1488732339.1412250549335
Content-Type: text/plain; charset=UTF-8
On Thursday, October 2, 2014 1:08:25 PM UTC+2, Douglas Boffey wrote:
>
>
> Do you mean goto case 3?
>
> I notice in all the examples you gave, the goto case instructions were
> forward gotos. Was that intentional or not?
>
The goto case 3 is a mistake, sorry.
And the fact that all goto case are forward goto isn't intentionnal. In
fact I see no reason why it should be necessary the 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/.
------=_Part_7169_1488732339.1412250549335
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, October 2, 2014 1:08:25 PM UTC+2, Dou=
glas Boffey wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div> </div>
<div>Do you mean goto case 3?</div>
<div> </div>
<div>I notice in all the examples you gave, the goto case instructions were=
forward gotos. Was that intentional or not?</div></blockquote><div><=
br>The goto case 3 is a mistake, sorry. <br>And the fact that all got=
o case are forward goto isn't intentionnal. In fact I see no reason why it =
should be necessary the case.<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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7169_1488732339.1412250549335--
.
Author: Ivo <ivo.doko@gmail.com>
Date: Fri, 3 Oct 2014 13:39:28 -0700 (PDT)
Raw View
------=_Part_867_987443136.1412368768254
Content-Type: text/plain; charset=UTF-8
I like this idea, however, I do not think labels are the right approach. I
think what should be done instead is to allow break and continue to accept
an optional non-negative integer argument, so for example this:
for(int i = 0; i < n; ++i)
for(int j = i; j < n; ++i)
if(j % 7 == 0) break(0);
would be equivalent to
for(int i = 0; i < n; ++i)
for(int j = i; j < n; ++i)
if(j % 7 == 0) break;
but
for(int i = 0; i < n; ++i)
for(int j = i; j < n; ++i)
if(j % 7 == 0) break(1);
would break the outer for-loop. Analogously, break(2) would break the loop
two levels above, etc.
--
---
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_867_987443136.1412368768254
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I like this idea, however, I do not think labels are the r=
ight approach. I think what should be done instead is to allow break and co=
ntinue to accept an optional non-negative integer argument, so for example =
this:<br><br>for(int i =3D 0; i < n; ++i)<br> for(int =
j =3D i; j < n; ++i)<br> if(j =
% 7 =3D=3D 0) break(0);<br><br>would be equivalent to<br><br><div class=3D"=
prettyprint" 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 class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> i </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&=
nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> j </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> j </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">++</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">i</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><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">j </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">%</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">7</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">break</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br>but<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
style=3D"color: #008;" class=3D"styled-by-prettify">for</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #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;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> n</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">++</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">i</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> j </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> i</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> j </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> n</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">++</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">i</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: #008;" class=3D"styled-by-prettify">if</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">j </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">%</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D=
"styled-by-prettify">7</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">1</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span></div></code></div><br>would break the outer for-loop. An=
alogously, break(2) would break the loop two levels above, etc.</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_867_987443136.1412368768254--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 03 Oct 2014 17:03:48 -0400
Raw View
On 2014-10-03 16:39, Ivo wrote:
> I like this idea, however, I do not think labels are the right approach. I
> think what should be done instead is to allow break and continue to accept
> an optional non-negative integer argument
We've had similar suggestions (e.g. 'break break'), and they've been
universally (AFAICT) less well received than labeled loops. The problem
is that they're more brittle, i.e. more prone to change meaning in less
obvious ways e.g. if another loop is inserted or removed.
I also prefer the labeled loops because the label is an opportunity to
name the loop: 'break token_processing' is much more readable than
'break(2)'.
(Oh, and... just occurred to me, as far as the complaint about having to
look up to find the label then down to find the brace, you'd have a
similar problem refactoring loops into functions - or worse, lambdas...
so I don't think that's a good argument against them.)
Since I'm writing now, and don't recall if I've explicitly weighed in
before: I'm weakly in favor of labeled breaks. (With slight preference
to the label following the control statement, e.g. 'for (...) loop_name:
{ ... }'.)
--
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: Ivo <ivo.doko@gmail.com>
Date: Fri, 3 Oct 2014 14:46:06 -0700 (PDT)
Raw View
------=_Part_8768_1085658658.1412372766971
Content-Type: text/plain; charset=UTF-8
On Friday, 3 October 2014 23:04:04 UTC+2, Matthew Woehlke wrote:
>
> We've had similar suggestions (e.g. 'break break'), and they've been
> universally (AFAICT) less well received than labeled loops. The problem
> is that they're more brittle, i.e. more prone to change meaning in less
> obvious ways e.g. if another loop is inserted or removed.
>
> I also prefer the labeled loops because the label is an opportunity to
> name the loop: 'break token_processing' is much more readable than
> 'break(2)'.
>
The reason I prefer break/continue with integer parameter over labels is
because the only other use of labels in C++ I can think of is for GOTO,
which should never be used, whereas we have integer (and other) arguments
everywhere in C++. Having an integer parameter just feels "more C++" in a
way, whereas introducing labels for this purpose just feels alien.
As for brittleness... that's debatable. Both approaches are "brittle" in a
certain sense. The integer argument approach is, as you have said, brittle
because introducing another loop level would mean all integer arguments for
relevant break/continue statements within need to increase by 1. However,
the label approach is brittle in a more obvious sense, i.e. if you change
the label of a loop you have to change that label for all relevant break/
continue statements within, which is also error-prone since you might
forget some of them.
Consider, however, which is more likely to happen while writing a program -
deciding to change the label of a loop, or having a nested loop and
introducing another loop within the outer loop which encompasses the inner
loop? Even if the latter is more likely, I cannot imagine not having to
extensively modify the newly encompassed loop after this change anyway, in
which case it is questionable if that loop was supposed to break/continue
the original loop anyway.
--
---
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_8768_1085658658.1412372766971
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, 3 October 2014 23:04:04 UTC+2, Matthew Woehlke =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">We've had similar sugge=
stions (e.g. 'break break'), and they've been
<br>universally (AFAICT) less well received than labeled loops. The problem
<br>is that they're more brittle, i.e. more prone to change meaning in less
<br>obvious ways e.g. if another loop is inserted or removed.
<br>
<br>I also prefer the labeled loops because the label is an opportunity to
<br>name the loop: 'break token_processing' is much more readable than
<br>'break(2)'.<br></blockquote><div><br>The reason I prefer <span style=3D=
"font-family: courier new,monospace;">break</span>/<span style=3D"font-fami=
ly: courier new,monospace;">continue</span> with integer parameter over lab=
els is because the only other use of labels in C++ I can think of is for <s=
pan style=3D"font-family: courier new,monospace;">GOTO</span>, which should=
never be used, whereas we have integer (and other) arguments everywhere in=
C++. Having an integer parameter just feels "more C++" in a way, whereas i=
ntroducing labels for this purpose just feels alien.<br><br>As for brittlen=
ess... that's debatable. Both approaches are "brittle" in a certain sense. =
The integer argument approach is, as you have said, brittle because introdu=
cing another loop level would mean all integer arguments for relevant <span=
style=3D"font-family: courier new,monospace;">break</span>/<span style=3D"=
font-family: courier new,monospace;">continue</span> statements within need=
to increase by 1. However, the label approach is brittle in a more obvious=
sense, i.e. if you change the label of a loop you have to change that labe=
l for all relevant <span style=3D"font-family: courier new,monospace;">brea=
k</span>/<span style=3D"font-family: courier new,monospace;">continue</span=
> statements within, which is also error-prone since you might forget some =
of them.<br><br>Consider, however, which is more likely to happen while wri=
ting a program - deciding to change the label of a loop, or having a nested=
loop and introducing another loop within the outer loop which encompasses =
the inner loop? Even if the latter is more likely, I cannot imagine not hav=
ing to extensively modify the newly encompassed loop after this change anyw=
ay, in which case it is questionable if that loop was supposed to break/con=
tinue the original loop anyway.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_8768_1085658658.1412372766971--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 03 Oct 2014 18:03:15 -0400
Raw View
On 2014-10-03 17:46, Ivo wrote:
> As for brittleness... that's debatable.
I respectfully disagree :-).
> However, the label approach is brittle in a more obvious sense, i.e.
> if you change the label of a loop you have to change that label for
> all relevant break/ continue statements within, which is also
> error-prone since you might forget some of them.
You "can't" forget... if you miss one, your code *won't build*, i.e. the
compiler will remind you and your changes can't go into production.
With an "indexed" approach, your code might build just fine, but the
algorithm could be broken. This brokenness might not be immediately
obvious, could conceivably sneak past code review and testing (assuming
you're even doing those), and could conceivably even go unnoticed for a
long time. That's *HUGELY* worse than the trivial inconvenience of the
compiler griping that it can't find a label because you changed it and
missed a spot.
In my (and others') opinion(s), the added safety soundly trumps typing
convenience. So does readability, for that matter. (Typing convenience
is in fact near the bottom on the list of priorities.)
--
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: Ivo <ivo.doko@gmail.com>
Date: Fri, 3 Oct 2014 15:59:31 -0700 (PDT)
Raw View
------=_Part_938_2078880098.1412377171181
Content-Type: text/plain; charset=UTF-8
On Saturday, 4 October 2014 00:03:39 UTC+2, Matthew Woehlke wrote:
>
> On 2014-10-03 17:46, Ivo wrote:
> > As for brittleness... that's debatable.
>
> I respectfully disagree :-).
>
> > However, the label approach is brittle in a more obvious sense, i.e.
> > if you change the label of a loop you have to change that label for
> > all relevant break/ continue statements within, which is also
> > error-prone since you might forget some of them.
>
> You "can't" forget... if you miss one, your code *won't build*, i.e. the
> compiler will remind you and your changes can't go into production.
>
> With an "indexed" approach, your code might build just fine, but the
> algorithm could be broken. This brokenness might not be immediately
> obvious, could conceivably sneak past code review and testing (assuming
> you're even doing those), and could conceivably even go unnoticed for a
> long time. That's *HUGELY* worse than the trivial inconvenience of the
> compiler griping that it can't find a label because you changed it and
> missed a spot.
>
> In my (and others') opinion(s), the added safety soundly trumps typing
> convenience. So does readability, for that matter. (Typing convenience
> is in fact near the bottom on the list of priorities.)
>
Be all that as it may, I still think my last paragraph in and of itself is
an important point - if your algorithm requires such a modification that
one (or more) of your inner loops needs to have another encompassing loop
added, you will need to completely restructure (i.e. just rewrite from
scratch) that loop anyway. There's no way that can end well otherwise,
labels or no labels.
--
---
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_938_2078880098.1412377171181
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, 4 October 2014 00:03:39 UTC+2, Matthew Woehlk=
e wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-10-03 17:46, =
Ivo wrote:
<br>> As for brittleness... that's debatable.
<br>
<br>I respectfully disagree :-).
<br>
<br>> However, the label approach is brittle in a more obvious sense, i.=
e.
<br>> if you change the label of a loop you have to change that label fo=
r
<br>> all relevant break/ continue statements within, which is also
<br>> error-prone since you might forget some of them.
<br>
<br>You "can't" forget... if you miss one, your code *won't build*, i.e. th=
e
<br>compiler will remind you and your changes can't go into production.
<br>
<br>With an "indexed" approach, your code might build just fine, but the
<br>algorithm could be broken. This brokenness might not be immediately
<br>obvious, could conceivably sneak past code review and testing (assuming
<br>you're even doing those), and could conceivably even go unnoticed for a
<br>long time. That's *HUGELY* worse than the trivial inconvenience of the
<br>compiler griping that it can't find a label because you changed it and
<br>missed a spot.
<br>
<br>In my (and others') opinion(s), the added safety soundly trumps typing
<br>convenience. So does readability, for that matter. (Typing convenience
<br>is in fact near the bottom on the list of priorities.)
<br></blockquote><div><br>Be all that as it may, I still think my last para=
graph in and of itself is an important point - if your algorithm requires s=
uch a modification that one (or more) of your inner loops needs to have ano=
ther encompassing loop added, you will need to completely restructure (i.e.=
just rewrite from scratch) that loop anyway. There's no way that can end w=
ell otherwise, labels or no labels.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_938_2078880098.1412377171181--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Mon, 6 Oct 2014 03:19:46 -0700 (PDT)
Raw View
------=_Part_935_1401389526.1412590786241
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Friday, 3 October 2014 22:46:07 UTC+1, Ivo wrote:
>
> On Friday, 3 October 2014 23:04:04 UTC+2, Matthew Woehlke wrote:
>>
>> We've had similar suggestions (e.g. 'break break'), and they've been=20
>> universally (AFAICT) less well received than labeled loops. The problem=
=20
>> is that they're more brittle, i.e. more prone to change meaning in less=
=20
>> obvious ways e.g. if another loop is inserted or removed.=20
>>
>> I also prefer the labeled loops because the label is an opportunity to=
=20
>> name the loop: 'break token_processing' is much more readable than=20
>> 'break(2)'.
>>
>
> The reason I prefer break/continue with integer parameter over labels is=
=20
> because the only other use of labels in C++ I can think of is for GOTO,=
=20
> which should never be used, whereas we have integer (and other) arguments=
=20
> everywhere in C++. Having an integer parameter just feels "more C++" in a=
=20
> way, whereas introducing labels for this purpose just feels alien.
>
> As for brittleness... that's debatable. Both approaches are "brittle" in =
a=20
> certain sense. The integer argument approach is, as you have said, brittl=
e=20
> because introducing another loop level would mean all integer arguments f=
or=20
> relevant break/continue statements within need to increase by 1. However,=
=20
> the label approach is brittle in a more obvious sense, i.e. if you change=
=20
> the label of a loop you have to change that label for all relevant break/
> continue statements within, which is also error-prone since you might=20
> forget some of them.
>
> Ah, labelling variables must, by the same token, be considered brittle=20
then=E2=80=94perhaps we should write code that uses a number of integer var=
iables=20
as a single array with each variable just being an index into this array,=
=20
after all, that would get rid of the brittleness of naming the variables )=
=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_935_1401389526.1412590786241
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>On Friday, 3 October 2014 22:46:07 UTC+1, Ivo wrote:<=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le=
ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so=
lid;" class=3D"gmail_quote"><div dir=3D"ltr">On Friday, 3 October 2014 23:0=
4:04 UTC+2, Matthew Woehlke wrote:<blockquote style=3D"margin: 0px 0px 0px=
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;" class=3D"gmail_quote">We've had s=
imilar suggestions (e.g. 'break break'), and they've been
<br>universally (AFAICT) less well received than labeled loops. The problem
<br>is that they're more brittle, i.e. more prone to change meaning in less
<br>obvious ways e.g. if another loop is inserted or removed.
<br>
<br>I also prefer the labeled loops because the label is an opportunity to
<br>name the loop: 'break token_processing' is much more readable than
<br>'break(2)'.<br></blockquote><div><br>The reason I prefer <span style=3D=
"font-family: courier new,monospace;">break</span>/<span style=3D"font-fami=
ly: courier new,monospace;">continue</span> with integer parameter over lab=
els is because the only other use of labels in C++ I can think of is for <s=
pan style=3D"font-family: courier new,monospace;">GOTO</span>, which should=
never be used, whereas we have integer (and other) arguments everywhere in=
C++. Having an integer parameter just feels "more C++" in a way, whereas i=
ntroducing labels for this purpose just feels alien.<br><br>As for brittlen=
ess... that's debatable. Both approaches are "brittle" in a certain sense. =
The integer argument approach is, as you have said, brittle because introdu=
cing another loop level would mean all integer arguments for relevant <span=
style=3D"font-family: courier new,monospace;">break</span>/<span style=3D"=
font-family: courier new,monospace;">continue</span> statements within need=
to increase by 1. However, the label approach is brittle in a more obvious=
sense, i.e. if you change the label of a loop you have to change that labe=
l for all relevant <span style=3D"font-family: courier new,monospace;">brea=
k</span>/<span style=3D"font-family: courier new,monospace;">continue</span=
> statements within, which is also error-prone since you might forget some =
of them.<br><br></div></div></blockquote><div>Ah, labelling variables must,=
by the same token, be considered brittle then=E2=80=94perhaps we should wr=
ite code that uses a number of integer variables as a single array with eac=
h variable just being an index into this array, after all, that w=
ould get rid of the brittleness of naming the variables ) </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_935_1401389526.1412590786241--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 6 Oct 2014 20:38:07 +0800
Raw View
--Apple-Mail=_A09BB57E-F947-47F8-BE80-406D76C7926D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-10-06, at 6:19 PM, Douglas Boffey <douglas.boffey@gmail.com> wrote:
> Ah, labelling variables must, by the same token, be considered brittle th=
en--perhaps we should write code that uses a number of integer variables as=
a single array with each variable just being an index into this array, aft=
er all, that would get rid of the brittleness of naming the variables )=20
One alternative would be to name the most recently declared variable int, t=
he previous one int int, etc.
(Actually, such a unary system is how binary lambda calculus works -- it's =
an efficient encoding! But not source code.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_A09BB57E-F947-47F8-BE80-406D76C7926D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;10–06, at 6:19 PM, Douglas Boffey <<a href=3D"mailto:douglas=
..boffey@gmail.com">douglas.boffey@gmail.com</a>> wrote:</div><br class=
=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div style=3D"font=
-family: Helvetica; font-size: 12px; font-style: normal; font-variant: norm=
al; font-weight: normal; letter-spacing: normal; line-height: normal; orpha=
ns: auto; text-align: start; text-indent: 0px; text-transform: none; white-=
space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: =
0px;"><div dir=3D"ltr">Ah, labelling variables must, by the same token, be =
considered brittle then—perhaps we should write code that uses a numb=
er of integer variables as a single array with each variable just bein=
g an index into this array, after all, that would get rid of the britt=
leness of naming the variables ) </div></div></blockquote><br></div><d=
iv>One alternative would be to name the most recently declared variable <fo=
nt face=3D"Courier">int</font>, the previous one <font face=3D"Courier">int=
int</font>, etc.</div><br><div>(Actually, such a unary system is how binar=
y lambda calculus works — it’s an efficient encoding! But not s=
ource code.)</div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_A09BB57E-F947-47F8-BE80-406D76C7926D--
.
Author: Ivo <ivo.doko@gmail.com>
Date: Mon, 6 Oct 2014 07:40:30 -0700 (PDT)
Raw View
------=_Part_10392_1042301972.1412606433273
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, 6 October 2014 12:19:46 UTC+2, Douglas Boffey wrote:
>
> Ah, labelling variables must, by the same token, be considered brittle=20
> then=E2=80=94perhaps we should write code that uses a number of integer v=
ariables=20
> as a single array with each variable just being an index into this array,=
=20
> after all, that would get rid of the brittleness of naming the variables =
)=20
>
Yes, that was sort of the point - this assessment of error-proneness of=20
labels is intended to be as anal as the assessment of error-proneness of=20
integer parameters. And actually, you only strengthen my point - changing=
=20
the name of a variable and forgetting to change it everywhere happens much=
=20
more frequently than encompassing a nested loop in another loop without=20
having to completely restructure the newly encompassed loop. So in fact, my=
=20
assessment is even less anal.
Your sarcasm skills are indeed truly remarkable, however, I would=20
appreciate it if instead of making snarky comments about something which is=
=20
completely irrelevant as an attempt to undermine my point you instead=20
retorted to what I said was my *actual* point, which is, once again:
If your algorithm requires such a modification that one (or more) of your=
=20
> inner loops needs to have another encompassing loop added, you will need =
to=20
> completely restructure (i.e. just rewrite from scratch) that loop anyway.=
=20
> There's no way that can end well otherwise, labels or no labels.
This renders the discussion of "labels are less/more error-prone than=20
integer parameters" completely moot. And, given that, I would rather not=20
introduce labels in C++ just so loops can be labelled but would prefer=20
passing an integer parameter, which is simply a more natural syntax in C++.
--=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_10392_1042301972.1412606433273
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, 6 October 2014 12:19:46 UTC+2, Douglas Boffey =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Ah=
, labelling variables must, by the same token, be considered brittle then=
=E2=80=94perhaps we should write code that uses a number of integer variabl=
es as a single array with each variable just being an index into =
this array, after all, that would get rid of the brittleness of naming the =
variables ) </div></div></blockquote><div><br>Yes, that was sort of th=
e point - this assessment of error-proneness of labels is intended to be as=
anal as the assessment of error-proneness of integer parameters. And actua=
lly, you only strengthen my point - changing the name of a variable and for=
getting to change it everywhere happens much more frequently than encompass=
ing a nested loop in another loop without having to completely restructure =
the newly encompassed loop. So in fact, my assessment is even less anal.<br=
><br>Your sarcasm skills are indeed truly remarkable, however, I would appr=
eciate it if instead of making snarky comments about something which is com=
pletely irrelevant as an attempt to undermine my point you instead retorted=
to what I said was my <i>actual</i> point, which is, once again:<br><br><b=
lockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(20=
4, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">If your algorithm r=
equires such a modification that one (or more) of=20
your inner loops needs to have another encompassing loop added, you will
need to completely restructure (i.e. just rewrite from scratch) that=20
loop anyway. There's no way that can end well otherwise, labels or no=20
labels.</blockquote><div><br>This renders the discussion of "labels are les=
s/more error-prone than integer parameters" completely moot. And, given tha=
t, I would rather not introduce labels in C++ just so loops can be labelled=
but would prefer passing an integer parameter, which is simply a more natu=
ral syntax in C++.<br></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_10392_1042301972.1412606433273--
.
Author: Douglas Boffey <douglas.boffey@gmail.com>
Date: Mon, 6 Oct 2014 11:24:54 -0700 (PDT)
Raw View
------=_Part_744_347871158.1412619894162
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, 6 October 2014 15:40:33 UTC+1, Ivo wrote:
>
> On Monday, 6 October 2014 12:19:46 UTC+2, Douglas Boffey wrote:
>>
>> Ah, labelling variables must, by the same token, be considered brittle=
=20
>> then=E2=80=94perhaps we should write code that uses a number of integer =
variables=20
>> as a single array with each variable just being an index into this array=
,=20
>> after all, that would get rid of the brittleness of naming the variables=
)=20
>>
>
> Yes, that was sort of the point - this assessment of error-proneness of=
=20
> labels is intended to be as anal as the assessment of error-proneness of=
=20
> integer parameters. And actually, you only strengthen my point - changing=
=20
> the name of a variable and forgetting to change it everywhere happens muc=
h=20
> more frequently than encompassing a nested loop in another loop without=
=20
> having to completely restructure the newly encompassed loop. So in fact, =
my=20
> assessment is even less anal.
>
> Your sarcasm skills are indeed truly remarkable, however, I would=20
> appreciate it if instead of making snarky comments about something which =
is=20
> completely irrelevant as an attempt to undermine my point you instead=20
> retorted to what I said was my *actual* point, which is, once again:
>
> If your algorithm requires such a modification that one (or more) of your=
=20
>> inner loops needs to have another encompassing loop added, you will need=
to=20
>> completely restructure (i.e. just rewrite from scratch) that loop anyway=
..=20
>> There's no way that can end well otherwise, labels or no labels.
>
>
> This renders the discussion of "labels are less/more error-prone than=20
> integer parameters" completely moot. And, given that, I would rather not=
=20
> introduce labels in C++ just so loops can be labelled but would prefer=20
> passing an integer parameter, which is simply a more natural syntax in C+=
+.
>
Firstly, my previous posting was not meant to be antagonistic=E2=80=94my ap=
ologies=20
that it was taken that way. I was merely trying to make a point, which is=
=20
that using numbers is cumbersome, and *very* low level. As for your=20
concluding argument about modifying code, as far as I=E2=80=99m concerned, =
that is=20
a non-argument=E2=80=94if enough of a modification of one=E2=80=99s code ma=
kes one=E2=80=99s=20
previous labelling redundant (or whatever), using integers would equally=20
troublesome.
Regarding integers being =E2=80=98a more natural syntax for C++=E2=80=99, t=
hat is highly=20
questionable. As for passing an integer to a function, making the level of=
=20
loop unnesting non-constant, do you not agree that a) it would make the=20
code more difficult to read, b) introduce inefficiencies, and c) it is=20
difficult to see what algorithm could benefit from such a proposition.
=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_744_347871158.1412619894162
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, 6 October 2014 15:40:33 UTC+1, Ivo wro=
te:<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 Monday,=
6 October 2014 12:19:46 UTC+2, Douglas Boffey 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>Ah, labelling variables must, by t=
he same token, be considered brittle then=E2=80=94perhaps we should write c=
ode that uses a number of integer variables as a single array with each var=
iable just being an index into this array, after all, that would =
get rid of the brittleness of naming the variables ) </div></div></blo=
ckquote><div><br>Yes, that was sort of the point - this assessment of error=
-proneness of labels is intended to be as anal as the assessment of error-p=
roneness of integer parameters. And actually, you only strengthen my point =
- changing the name of a variable and forgetting to change it everywhere ha=
ppens much more frequently than encompassing a nested loop in another loop =
without having to completely restructure the newly encompassed loop. So in =
fact, my assessment is even less anal.<br><br>Your sarcasm skills are indee=
d truly remarkable, however, I would appreciate it if instead of making sna=
rky comments about something which is completely irrelevant as an attempt t=
o undermine my point you instead retorted to what I said was my <i>actual</=
i> point, which is, once again:<br><br><blockquote style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D=
"gmail_quote">If your algorithm requires such a modification that one (or m=
ore) of=20
your inner loops needs to have another encompassing loop added, you will
need to completely restructure (i.e. just rewrite from scratch) that=20
loop anyway. There's no way that can end well otherwise, labels or no=20
labels.</blockquote><div><br>This renders the discussion of "labels are les=
s/more error-prone than integer parameters" completely moot. And, given tha=
t, I would rather not introduce labels in C++ just so loops can be labelled=
but would prefer passing an integer parameter, which is simply a more natu=
ral syntax in C++.<br></div></div></div></blockquote><div><br>Firstly, my p=
revious posting was not meant to be antagonistic=E2=80=94my apologies that =
it was taken that way. I was merely trying to make a point, which is =
that using numbers is cumbersome, and <i>very</i> low level. As for y=
our concluding argument about modifying code, as far as I=E2=80=99m concern=
ed, that is a non-argument=E2=80=94if enough of a modification of one=E2=80=
=99s code makes one=E2=80=99s previous labelling redundant (or whatever), u=
sing integers would equally troublesome.<br><br>Regarding integers being =
=E2=80=98a more natural syntax for C++=E2=80=99, that is highly questionabl=
e. As for passing an integer to a function, making the level of loop =
unnesting non-constant, do you not agree that a) it would make the code mor=
e difficult to read, b) introduce inefficiencies, and c) it is difficult to=
see what algorithm could benefit from such a proposition.<br><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 <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_744_347871158.1412619894162--
.
Author: Myriachan <myriachan@gmail.com>
Date: Mon, 6 Oct 2014 12:34:47 -0700 (PDT)
Raw View
------=_Part_923_990386081.1412624087795
Content-Type: text/plain; charset=UTF-8
On Monday, October 6, 2014 7:40:33 AM UTC-7, Ivo wrote:
>
> On Monday, 6 October 2014 12:19:46 UTC+2, Douglas Boffey wrote:
>
> If your algorithm requires such a modification that one (or more) of your
>> inner loops needs to have another encompassing loop added, you will need to
>> completely restructure (i.e. just rewrite from scratch) that loop anyway.
>> There's no way that can end well otherwise, labels or no labels.
>
>
> This renders the discussion of "labels are less/more error-prone than
> integer parameters" completely moot. And, given that, I would rather not
> introduce labels in C++ just so loops can be labelled but would prefer
> passing an integer parameter, which is simply a more natural syntax in C++.
>
The point of labeled break/continue is to allow a slightly cleaner
variation of existing practice. C++ programmers already use goto to
accomplish this task with labels--this would just change the location of
the labels and make them less error-prone. Also, it'd allow better nested
loop exit in constexpr functions, in which goto is not allowed in C++14.
So this isn't introducing labels at all--labels are already here, and
allowing labeled break and continue simplifies some code.
Melissa
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_923_990386081.1412624087795
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, October 6, 2014 7:40:33 AM UTC-7, Ivo wrote:<bl=
ockquote 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 Monday, 6 Oct=
ober 2014 12:19:46 UTC+2, Douglas Boffey wrote:<br><div><br><blockquote st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex" class=3D"gmail_quote">If your algorithm requires such a modif=
ication that one (or more) of=20
your inner loops needs to have another encompassing loop added, you will
need to completely restructure (i.e. just rewrite from scratch) that=20
loop anyway. There's no way that can end well otherwise, labels or no=20
labels.</blockquote><div><br>This renders the discussion of "labels are les=
s/more error-prone than integer parameters" completely moot. And, given tha=
t, I would rather not introduce labels in C++ just so loops can be labelled=
but would prefer passing an integer parameter, which is simply a more natu=
ral syntax in C++.<br></div></div></div></blockquote><div><br><br>The point=
of labeled <span style=3D"font-family: courier new,monospace;">break</span=
>/<span style=3D"font-family: courier new,monospace;">continue</span> is to=
allow a slightly cleaner variation of existing practice. C++ program=
mers already use <span style=3D"font-family: courier new,monospace;">goto</=
span> to accomplish this task with labels--this would just change the locat=
ion of the labels and make them less error-prone. Also, it'd allow be=
tter nested loop exit in <span style=3D"font-family: courier new,monospace;=
">constexpr</span> functions, in which <span style=3D"font-family: courier =
new,monospace;">goto</span> is not allowed in C++14. So this isn't in=
troducing labels at all--labels are already here, and allowing labeled <spa=
n style=3D"font-family: courier new,monospace;">break</span> and <span styl=
e=3D"font-family: courier new,monospace;">continue</span> simplifies some c=
ode.<br><br>Melissa<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_923_990386081.1412624087795--
.
Author: Ivo <ivo.doko@gmail.com>
Date: Mon, 6 Oct 2014 12:39:55 -0700 (PDT)
Raw View
------=_Part_1537_930900752.1412624395192
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, 6 October 2014 20:24:54 UTC+2, Douglas Boffey wrote:
>
> Firstly, my previous posting was not meant to be antagonistic=E2=80=94my =
apologies=20
> that it was taken that way.
>
I apologise as well. It has not been a good day for me, spent the entire=20
night awake trying to figure out why and how I'm getting a linker error for=
=20
only two of three constexprs defined completely analogously, but only when=
=20
I disable compiler optimisation... (still have no idea, but suspecting some=
=20
weird bug in the compiler). But anyway
I was merely trying to make a point, which is that using numbers is=20
> cumbersome, and *very* low level. As for your concluding argument about=
=20
> modifying code, as far as I=E2=80=99m concerned, that is a non-argument=
=E2=80=94if enough=20
> of a modification of one=E2=80=99s code makes one=E2=80=99s previous labe=
lling redundant=20
> (or whatever), using integers would equally troublesome.
>
> Regarding integers being =E2=80=98a more natural syntax for C++=E2=80=99,=
that is highly=20
> questionable.=20
>
Yes, they would be *equally* cumbersome, which is all I was trying to say=
=20
anyway. Whether one is more cumbersome than the other, that's a matter of=
=20
taste really. Something similar could be said for it being low-level - C++=
=20
is, relatively speaking, a low-level language. Moreover, we're talking=20
about nested loops and breaking/continuing the outer loop from the inner=20
loop. That's sort of low-level in itself.
What I mean by "natural syntax" is simply that currently there are pretty=
=20
much no labels in C++, at least not in this sense, unless you want to do=20
GOTO. Integer arguments, on the other hand, are pervasive -=20
As for passing an integer to a function, making the level of loop unnesting=
=20
> non-constant, do you not agree that a) it would make the code more=20
> difficult to read, b) introduce inefficiencies, and c) it is difficult to=
=20
> see what algorithm could benefit from such a proposition.
>
Well, it definitely wouldn't introduce inefficiencies, since (hopefully)=20
the resolution of the integer arguments would be done at compile-time.=20
Indeed, I can imagine no algorithm which would benefit from having a=20
variable integer passed to break or continue, other than perhaps some=20
ludicrously silly PRNG. So no, I did not mean a variable argument, but a=20
constant. constexpr sort of constant, in fact. With that in mind, I don't=
=20
think it would be particularly difficult to read. Whether a loop is given a=
=20
"name" and referred to by it or is referred to by how many "levels above"=
=20
an inner loop it is... it's pretty much the same, I think.
At the end of the day, I think both approaches would be fine. Now I feel=20
like I'm nitpicking practically over nothing, so...
--=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_1537_930900752.1412624395192
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Monday, 6 October 2014 20:24:54 UTC+2, Douglas Boffey =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Fi=
rstly, my previous posting was not meant to be antagonistic=E2=80=94my apol=
ogies that it was taken that way.</div></div></blockquote><div><br>I apolog=
ise as well. It has not been a good day for me, spent the entire night awak=
e trying to figure out why and how I'm getting a linker error for only two =
of three <span style=3D"font-family: courier new,monospace;">constexpr</spa=
n>s defined completely analogously, but only when I disable compiler optimi=
sation... (still have no idea, but suspecting some weird bug in the compile=
r). But anyway<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div>I was merely trying to make a point, which is that usin=
g numbers is cumbersome, and <i>very</i> low level. As for your concl=
uding argument about modifying code, as far as I=E2=80=99m concerned, that =
is a non-argument=E2=80=94if enough of a modification of one=E2=80=99s code=
makes one=E2=80=99s previous labelling redundant (or whatever), using inte=
gers would equally troublesome.</div></div></blockquote><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote"><div><br></div></blockquote><div><=
/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"lt=
r"><div>Regarding integers being =E2=80=98a more natural syntax for C++=E2=
=80=99, that is highly questionable. </div></div></blockquote><div><br>Yes,=
they would be <i>equally</i> cumbersome, which is all I was trying to say =
anyway. Whether one is more cumbersome than the other, that's a matter of t=
aste really. Something similar could be said for it being low-level - C++ i=
s, relatively speaking, a low-level language. Moreover, we're talking about=
nested loops and breaking/continuing the outer loop from the inner loop. T=
hat's sort of low-level in itself.<br><br>What I mean by "natural syntax" i=
s simply that currently there are pretty much no labels in C++, at least no=
t in this sense, unless you want to do <span style=3D"font-family: courier =
new,monospace;">GOTO</span>. Integer arguments, on the other hand, are perv=
asive - <br><br></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>As for passing an integer to a function, making the level of =
loop unnesting non-constant, do you not agree that a) it would make the cod=
e more difficult to read, b) introduce inefficiencies, and c) it is difficu=
lt to see what algorithm could benefit from such a proposition.<br></div></=
div></blockquote><div><br>Well, it definitely wouldn't introduce inefficien=
cies, since (hopefully) the resolution of the integer arguments would be do=
ne at compile-time. Indeed, I can imagine no algorithm which would benefit =
from having a variable integer passed to <span style=3D"font-family: courie=
r new,monospace;">break</span> or <span style=3D"font-family: courier new,m=
onospace;">continue</span>, other than perhaps some ludicrously silly PRNG.=
So no, I did not mean a variable argument, but a constant. <span style=3D"=
font-family: courier new,monospace;">constexpr</span> sort of constant, in =
fact. With that in mind, I don't think it would be particularly difficult t=
o read. Whether a loop is given a "name" and referred to by it or is referr=
ed to by how many "levels above" an inner loop it is... it's pretty much th=
e same, I think.<br><br>At the end of the day, I think both approaches woul=
d be fine. Now I feel like I'm nitpicking practically over nothing, so...<b=
r></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1537_930900752.1412624395192--
.