Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote in message news:<HBF.20010829w07i@bombur.uio.no>...
> cizarre@gmx.net (Michael Andres) writes:
> >     case 'd':  // ...
> >                for(;;)
> >                  f();
> >                // ok: because of "for(;;)" the end of
> >                // this case-block can never be reached
> >
> >     case 'e':  // ...
>
> Require a break here.  If you begin to demand flow-control
> analysis from the compiler, where do you stop?

I would like to suggest a better and more detailed definition
of the flow-control analysis based on the comments given in
the postings.

The following is roughly how it might look like. I am not sure
if it is an ideal definition but at least it can be a start
for a discussion.

Some other definitions that are necessary for explaining the
algorithm are provided as well.


- Definition of case-block:

a) Within a statement-sequence that includes case-labelled-statements,
   those statements that are between two case-labelled-statements, are
   considered to form a partial statement-sequence named case-block.
   (case-block type a)

   (The beginning statement of the two case-labelled-statements
   is meant to be included, the terminating statement of the two
   case-labelled-statements is meant to be _not_ included.)

b) All statements that precede the first case-labelled-statement within
   the same statement-sequence are considered to form a case-block too.
   (case-block type b)

c) Furthermore all statements after the last case-labelled-statement
   until the last statement within the same statement-sequence are
   considered to form a case-block.
   (case-block type c)


- Case labels:

A case-labelled-statement is meant to be:
      case-label statement
(There can be more than one case-label for a statement.)

A case-label is meant to be:
      case constant-expression :
      default :


- Definition of the algorithm for the static flow analysis:

A case-block which precedes a case-labelled-statement (types a
and b of case-block) shall have to be an "obvious-noreturn".

The following are considered to be an obvious-noreturn:

1. a jump out of the enclosing switch
2. a fallthru-statement
3. a throw-statement    [C++ only]
4. a statement-sequence ending in an obvious-noreturn
5. a compound-statement with a statement-sequence ending
         in an obvious-noreturn
6. an if-statement with an else part, in which both branches
         are an obvious-noreturn
7. a try-block in which the try part and all catch parts
         are an obvious-noreturn    [C++ only]

A jump out of the enclosing switch is meant to be one of
the following:

1. a break-statement
2. a return-statement    [seriously: return is considered
         to be obviously not returning! :-) ]
3. a goto-statement that jumps out of the   enclosing switch
4. a continue-statement    [if valid at all]


- fallthru-statement:

A fallthru-statement is considered to be like a jump (goto) forward
to a point directly after the last statement of a case-block.
Constraint: A fallthru-statement shall have to be the last statement
in a case-block.

One consequence: A fallthru prior to the first case-label is not
illegal. Another consequence: A fallthru after the last case-label
is not illegal.

Example 1:

      switch (ch) {
            if (any) {
                                                                                                fallthru; // like: goto after_last_0;
                  case '1':    after_last_0:    f();
                                fallthru; // like: goto after_last_1;
                  case '2':    after_last_1:    fallthru; // like: goto after_last_2;
                                                   after_last_2:
            }
      }

However, the first and last fallthru in the example are valid but
redundant, so the example is equivalent to
example 2:

      switch (ch) {
            if (any) {
                  case '1':  f();
                 fallthru;
                  case '2':      ;
            }
      }

which is equivalent to
example 3:

      switch (ch)   if (any)   case '1': f();  // conforming to suggested syntax!



- fallthru switch:

Fall through behaviour for every case-block (just like it is in the
switch definition of the current standard).

Example 4:

      fallthru switch (ch) {
            case 'a': /* (statement a) */ ; // fall through to statement b
            case 'b': /* (statement b) */ ; // fall through to statement c
            case 'c': /* (statement c) */ ; // fall through to statement d
            case 'd': /* (statement d) */ ;
      }


Some of the simplifications in the algorithm for the flow analysis:
- only goto-statements that *leave* the switch are considered
- break or return, etc. in loops are not considered

Reasons for the simplification:
- easier analysis
- easier to read (sometimes break at the end of a case-block required)



 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B976A77.EEB5033C@aixigo.de>...
> ...
> If you have a library (e.g. Roguewave) and it issues thousands of
> warnings, you're no longer able to see the warnings of your own code.
> And my compiler isn't able to suppress warnings only for given library.
> OTOH disabling the warning completely isn't an option for me either as I
> want the warning if it's right.

If there were a standardized way to mark a source file with the
version of the standard under which it was written then this
problem could be avoided.

A compiler could then issue warnings depending on the version info.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

iddw@hotmail.com (Dave Hansen) wrote in message news:<3b965541.99352460@News.CIS.DFN.DE>...
> On Mon,  3 Sep 2001 21:35:38 GMT, cizarre@gmx.net (Michael Andres)
> wrote:
>
> [...]
> >
> >Ok, plan B:
> >
> >- "switch" stays like it is.
> >- Compilers issue a *warning* when they detect fall-through behaviour
> >  in a switch (e.g. based on a missing break or return or throw).
> >- The warning can be suppressed if fall-through is the intended
> >  behaviour.
>
> That's allowed today.  Contact your compiler vendor(s).
>
> Or get a good lint.  Gimpel's PC-lint behaves like this.  The
> fallthrough keyword is spelled differently, but I believe it can be
> hidden in a #define to make it look the way you want it to...
>

Good thing! But a standard is responsible for avoiding things like
different spellings.

A standardized behaviour would be desirable for compilers as well as
for external tools like lint.

I would like to become it part of the standard.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0109062253.6553e9f1@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>If there were a standardized way to mark a source file with the
>version of the standard under which it was written then this
>problem could be avoided.
>
>A compiler could then issue warnings depending on the version info.

I like this idea. It works for other things, like HTML / XML. Maybe we
should start doing this in source code to create a de-facto standard...
--
Conor O'Neill, Bristol, UK
Speaking for myself, not my Employer

This e-mail and any attachment is for authorised use by the intended recipient(s) only.  It may contain proprietary material, confidential information and/or be subject to legal privilege.  It should not be copied, disclosed to, retained or used by, any other party.  If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender.  Thank you.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
> If there were a standardized way to mark a source file with the
> version of the standard under which it was written then this
> problem could be avoided.
> A compiler could then issue warnings depending on the version info.

It doesn't serve the general programming community to tie source
code to specific versions of the language standard.  If the
program actually *needs* to take into account the version of the
standard that is supported by the implementation, there is already
a standard predefined macro for the purpose.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Douglas A. Gwyn" <DAGwyn@null.net> wrote in message news:<3B9D1CD9.E74BA8FF@null.net>...
> Michael Andres wrote:
> > If there were a standardized way to mark a source file with the
> > version of the standard under which it was written then this
> > problem could be avoided.
> > A compiler could then issue warnings depending on the version info.
>
> It doesn't serve the general programming community to tie
> source code to specific versions of the language standard.

If a language standard introduces a new facility then code that
makes use of it is tied to that version of the language standard.

Where exactly do you see the problem?

I have opened a thread "Standardized Standard Version Info". Can you
post your answer to that thread?


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Conor O'Neill" <ONeillCJ@logica.com> wrote in message news:<khh7oYCw+Kn7EwLe@adt285.aethos.co.uk>...
> In article <8fbd32b9.0109062253.6553e9f1@posting.google.com>, Michael
> Andres <cizarre@gmx.net> writes
> >If there were a standardized way to mark a source file with the
> >version of the standard under which it was written then this
> >problem could be avoided.
> >
> >A compiler could then issue warnings depending on the version info.
>
> I like this idea. It works for other things, like HTML / XML. Maybe we
> should start doing this in source code to create a de-facto standard...

I have opened a thread "Standardized Standard Version Info".


 - Michael


> --
> Conor O'Neill, Bristol, UK
> Speaking for myself, not my Employer
>
> This e-mail and any attachment is for authorised use by the intended
recipient(s) only.  It may contain proprietary material, confidential
information and/or be subject to legal privilege.  It should not be
copied, disclosed to, retained or used by, any other party.  If you
are not an intended recipient then please promptly delete this e-mail
and any attachment and all copies and inform the sender.  Thank you.
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B94832F.DE0AFE15@aixigo.de>...
> Michael Andres wrote:
> >
> > Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B8E019E.E48 0504C@aixigo.de>...
> ...
> >
> > Ok, plan B:
> >
> > - "switch" stays like it is.
> Agreed :)
I expected that answer. :)

> ...
> > - The warning can be suppressed if fall-through is the intended
> >   behaviour.
> As we are talking about compilers and not the language anymore,

That is definitely not what I am saying. On the contrary:
A diversification of such a feature depending on the platform
would not be useful. That's why it should become a language
feature.

Of course the warning should be optional, but compilers need
a standardized criterion to differentiate between intended and
unintended code (no matter with which compiler the code was
written originally).

> ...
> It's again the "how can I know the end is reached"-thing. For
> one compiler you'll have to add 'fallthru' as it cannot detect
> that a block never reaches it's end while another compiler may
> be better in detecting it.

The fact that the ability to analyze code, based on static flow
analysis varies from compiler to compiler doesn't mean it is
impossible to define an unambiguous algorithm for the proposed
functioning. Keeping the algorithm simple would probably also
improve readability of the code.

On the other hand I am not sure if this would really be so important.
If a compiler with less sophisticated flow analysis would complain
about a possibly unintended fall through behaviour, it could be
pacified either by adding "fallthru" *or* (depending on the
programmer's intention) something that the compiler would be able
to detect (e.g. "break"). After that, a compiler with a deeper
analysis would be satisfied as well.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0109022339.572ad8da@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>- "switch" stays like it is.

Good.

>- Compilers issue a *warning* when they detect fall-through behaviour
>  in a switch (e.g. based on a missing break or return or throw).

The Standard does not have a concept of "warning".

>- The warning can be suppressed if fall-through is the intended
>  behaviour.
>Compilers could be modified to issue this type of warnings
>independently
>of a standard, but it would not be helpful to have different keywords
>for "fallthru" on different platforms.

I'm not convinced that there are anywhere near enough compilers that do
this to make it worthwhile (particularly since such code is legal and
many people think that a "clean" compile is desirable).

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>=20
> Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B94832F.DE0=
AFE15@aixigo.de>...
> > Michael Andres wrote:
> > >
> > > Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B8E019E=
.E48 0504C@aixigo.de>...
> > ...
> > >
> > > Ok, plan B:
> > >
> > > - "switch" stays like it is.
> > Agreed :)
> I expected that answer. :)
>=20
> > ...
> > > - The warning can be suppressed if fall-through is the intended
> > >   behaviour.
> > As we are talking about compilers and not the language anymore,
>=20
> That is definitely not what I am saying. On the contrary:
> A diversification of such a feature depending on the platform
> would not be useful. That's why it should become a language
> feature.

Reasonable, but dangerous. See below...

> Of course the warning should be optional, but compilers need
> a standardized criterion to differentiate between intended and
> unintended code (no matter with which compiler the code was
> written originally).
>=20
> > ...
> > It's again the "how can I know the end is reached"-thing. For
> > one compiler you'll have to add 'fallthru' as it cannot detect
> > that a block never reaches it's end while another compiler may
> > be better in detecting it.
>=20
> The fact that the ability to analyze code, based on static flow
> analysis varies from compiler to compiler doesn't mean it is
> impossible to define an unambiguous algorithm for the proposed
> functioning. Keeping the algorithm simple would probably also
> improve readability of the code.

But this algorithms seems to be the real problem.

> On the other hand I am not sure if this would really be so important.
> If a compiler with less sophisticated flow analysis would complain
> about a possibly unintended fall through behaviour, it could be
> pacified either by adding "fallthru" *or* (depending on the
> programmer's intention) something that the compiler would be able
> to detect (e.g. "break"). After that, a compiler with a deeper
> analysis would be satisfied as well.

So we are sticked to the lowest common flow analysis. What if a compiler
isn't able to find out that

label: if( ... ) break; else goto label;

will not require 'break;' after it? This makes improvements impossible
and will lead to code that makes me think that there *must* be a way to
reach the final 'break;', otherwise, it won't be there. In my code, I
have a #define UNREACHABLE ... that could help here, but are you willing
to add an "unreachable" to the language, too?

To sum it up: I think your suggestion is reasonable and could be a good
idea, if you manage to find a clear, easy, unambiguous, flexible,
intuitive, extendable description of the flow analysis that doesn't
yield new supprises to the programmer. I've seen enough code like 'i =3D
i' to suppress compiler warnings (e.g. about unused variables) and I
have seen enough problems resulting from that code (i=3Di in a template
automatically requires the type of 'i' to have an operator=3D(). If you
don't have it, you're stuck). I just want to make sure that the number
of these problems doesn't exceed to number of problem resulting from the
current definition of 'switch'.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Mon,  3 Sep 2001 21:35:38 GMT, cizarre@gmx.net (Michael Andres)
wrote:

[...]
>
>Ok, plan B:
>
>- "switch" stays like it is.
>- Compilers issue a *warning* when they detect fall-through behaviour
>  in a switch (e.g. based on a missing break or return or throw).
>- The warning can be suppressed if fall-through is the intended
>  behaviour.

That's allowed today.  Contact your compiler vendor(s).

Or get a good lint.  Gimpel's PC-lint behaves like this.  The
fallthrough keyword is spelled differently, but I believe it can be
hidden in a #define to make it look the way you want it to...

Regards,

                               -=Dave
--
Change is inevitable, progress is not.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <W3nH+CQF4bl7EwMQ@romana.davros.org>,
Clive D. W. Feather <clive@davros.org> wrote:
>In article <8fbd32b9.0109022339.572ad8da@posting.google.com>, Michael
>Andres <cizarre@gmx.net> writes
>>- "switch" stays like it is.
>
>Good.
>
>>- Compilers issue a *warning* when they detect fall-through behaviour
>>  in a switch (e.g. based on a missing break or return or throw).
>
>The Standard does not have a concept of "warning".

The way standards often accomplish this is by deprecating it.  The
implication that a future revision of the standard may remove something
entirely is a strong suggestion that current implementations should warn
about uses.  But deprecation is not a promise to remove something, so you
could just keep deprecating it in every revision.

--
Barry Margolin, barmar@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B95F1DF.9CD8FFC0@aixigo.de>...
> ...
> To sum it up: I think your suggestion is reasonable and could be a good
> idea, if you manage to find a clear, easy, unambiguous, flexible,
> intuitive, extendable description of the flow analysis that doesn't
> yield new supprises to the programmer.

That would be the optimum.
I found the following warning option in a compiler:
  "possible use of 'identifier' before definition"
  This warning would be issued in a case like
    for(int i; i < 10; ++i) {
    }

The word "possible" implies that the compiler is not always
able to analyze the code. But the warning is a help!


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>=20
> Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B95F1DF.9CD=
8FFC0@aixigo.de>...
> > ...
> > To sum it up: I think your suggestion is reasonable and could be a go=
od
> > idea, if you manage to find a clear, easy, unambiguous, flexible,
> > intuitive, extendable description of the flow analysis that doesn't
> > yield new supprises to the programmer.
>=20
> That would be the optimum.
> I found the following warning option in a compiler:
>   "possible use of 'identifier' before definition"
>   This warning would be issued in a case like
>     for(int i; i < 10; ++i) {
>     }
>=20
> The word "possible" implies that the compiler is not always
> able to analyze the code. But the warning is a help!

If it is right on warning you. If the warning results from situations
where the code is clear, it messes up the output and can be a real pain.
If you have a library (e.g. Roguewave) and it issues thousands of
warnings, you're no longer able to see the warnings of your own code.
And my compiler isn't able to suppress warnings only for given library.
OTOH disabling the warning completely isn't an option for me either as I
want the warning if it's right.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Clive D. W. Feather" <clive@on-the-train.demon.co.uk> wrote in message news:<W3nH+CQF4bl7EwMQ@romana.davros.org>...
> In article <8fbd32b9.0109022339.572ad8da@posting.google.com>, Michael
> Andres <cizarre@gmx.net> writes
> >- The warning can be suppressed if fall-through is the intended
> >  behaviour.
> >Compilers could be modified to issue this type of warnings
> >independently
> >of a standard, but it would not be helpful to have different keywords
> >for "fallthru" on different platforms.
>
> I'm not convinced that there are anywhere near enough compilers that do
> this to make it worthwhile (particularly since such code is legal and
> many people think that a "clean" compile is desirable).

I found the following warning option in a compiler:
  "style of function definition is now obsolete"
  For cases like
    example(i)
    {
    }
  the compiler would issue the warning.

The desire for a "clean" compile is certainly very high in a
project with too many of these warnings, and the warning will
probably be disabled in such a project.
But in other projects it can be a useful option. It would be
a help for migration to the other declaration style.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey wrote:
>
> So we are sticked to the lowest common flow analysis. What if a compiler
> isn't able to find out that
>
> label: if( ... ) break; else goto label;
>
> will not require 'break;' after it? This makes improvements impossible
> and will lead to code that makes me think that there *must* be a way to
> reach the final 'break;', otherwise, it won't be there. In my code, I
> have a #define UNREACHABLE ... that could help here, but are you willing
> to add an "unreachable" to the language, too?

At least there is a precedent now in the Java language. Some amount of
flow analysis is part of the language specification; for example flow
analysis is required to determine that every variable is initialised
before it is used, and the exact algorithm for this analysis is part of
the language (that means any two conforming compilers would agree
whether a variable is initialised or not).

BTW. A Java compiler would determine that control flow in your example
will not proceed to the next statement.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Christian Bau <christian.bau@isltd.insignia.com> wrote in message news:<3B974CD6.E7147BCF@isltd.insignia.com>...
> Daniel Frey wrote:
> >
> > So we are sticked to the lowest common flow analysis. What if a compiler
> > isn't able to find out that
> >
> > label: if( ... ) break; else goto label;
> >
> > will not require 'break;' after it? This makes improvements impossible
> > and will lead to code that makes me think that there *must* be a way to
> > reach the final 'break;', otherwise, it won't be there. In my code, I
> > have a #define UNREACHABLE ... that could help here, but are you willing
> > to add an "unreachable" to the language, too?
>
> At least there is a precedent now in the Java language. Some amount of
> flow analysis is part of the language specification; for example flow
> analysis is required to determine that every variable is initialised
> before it is used, and the exact algorithm for this analysis is part of
> the language (that means any two conforming compilers would agree
> whether a variable is initialised or not).
>
> BTW. A Java compiler would determine that control flow in your example
> will not proceed to the next statement.

The "equivalent" for "unreachable" in the example would be a break at
the end. Right?


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

clive@on-the-train.demon.co.uk (Clive D. W. Feather)  wrote on 27.08.01 in <SPrGwJIp+li7EwXM@romana.davros.org>:

> You don't even need a new keyword: "auto switch" or "switch case" or
> some such combination could be used.

"restrict switch".


Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Codey wrote:
> "Jeff Howe" <jeffh@delorme.com> wrote in message
> news:10EBCFD1BEF2D2119E2300105A98299B04337F91@china1.delorme.com...
>
>>"Hallvard B Furuseth" <h.b.furuseth@usit.uio.no
>><mailto:h.b.furuseth@usit.uio.no>> wrote in message
>><news:HBF.20010829w07i@bombur.uio.no>...> cizarre@gmx.net
>><mailto:cizarre@gmx.net> <snip>
>>
>>>If you want every case block to have its own scope, I suggest you use
>>>a different syntax and require the braces. E.g.
>>>
>>>auto switch (i) {
>>>case (1) {
>>>int j;
>>>bar(&j);
>>>/* might just as well let break; be implicit too */
>>>}
>>>case (2) {
>>>baz(&j);
>>>}
>>>}
>>>
>>>
>>And while we're at it, maybe we could also add non-constant
>>case expressions also, e.g.
>>
>>int n = foob();
>>int m = boof();
>>auto switch (i) {
>>   case (n) {
>>      int j;
>>      bar(&j);
>>      }
>>   case (m) {
>>      baz(&j);
>>      }
>>   }
>>
>
> if you do that it will be harder for the compiler to optimise
> the generated machine code because it won't know the range of
> values (eg. using a jump table).

This is a non-issue; in all currently valid cases, the compiler
will still be able to optimize just as it does at the moment.
So, this extension satisfies the "zero cost" criterion.  If you
don't use it, you don't pay.

>  If you want to do this why
> not use an if/else statement. that is what it is there for.

No; if/else is more general.  Using the simplest control
structure which expresses the intent of code leads to clear
code.  If I see the start of a multi-way if/else then I don't
know if the conditions further down will be particularly
related to those at the start, but if I see a switch then
I know that they're all test of a given variable for
equality against other things.

To my mind the biggest improvement would be that allowing
things which aren't compile-time constant expressions would
let us do

std::string input("example");
switch (input) {
case "example": /* whatever */ break;
case "other":   /* whatever */ break;
}

So making std::string (and other concrete types) that much
closer to full language support.

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

kaih=883a$rZHw-B@khms.westfalen.de (Kai Henningsen) wrote in message news:<883a$rZHw-B@khms.westfalen.de>...
> clive@on-the-train.demon.co.uk (Clive D. W. Feather)  wrote on 27.08.01 in <SPrGwJIp+li7EwXM@romana.davros.org>:
>
> > You don't even need a new keyword: "auto switch" or "switch case" or
> > some such combination could be used.
>
> "restrict switch".
>

Why not "static switch"? "static" is over-overloaded anyway.

But for a syntax that should be preferred, it should be less typing, even
less than "switch".

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B8E019E.E480504C@aixigo.de>...

> ...
> If someone notices he makes mistakes when he uses switch, why
> does he use it anyway?

How can programmer A avoid the mistake if he uses code written by
programmer B?


But I agree it looks like the benefits of the proposal would
be too low to justify the costs. (Although it would be
interesting to see statistics about it.) Also, some problems
would not be solved and there would be some new problems.


Ok, plan B:

- "switch" stays like it is.
- Compilers issue a *warning* when they detect fall-through behaviour
  in a switch (e.g. based on a missing break or return or throw).
- The warning can be suppressed if fall-through is the intended
  behaviour.


Example 1:

  // ...
  case 'm': // ...
            fallthru;  // suppresses warning
  case 'n': // ...


Example 2:

  fallthru switch ()  // suppresses warnings for the complete switch
  // ...


Compilers could be modified to issue this type of warnings
independently
of a standard, but it would not be helpful to have different keywords
for "fallthru" on different platforms.
So, a minimum set of things should be standardized (just like the
keyword, which could be "fallthru" or a combination of "fallthru" and
"_Fallthru" similar to "bool" and "_Bool").



 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

#if IN_THE_WORST_CSC_TRADITION
Clive D. W. Feather <clive@on-the-train.demon.co.uk> wrote :
> In article <HBF.20010829w07i@bombur.uio.no>, Hallvard B Furuseth
> <h.b.furuseth@usit.uio.no> writes
> >Should it figure out that this loop will never end?
....
> Or this ?
>
>      unsigned int a, b, c, n;
>      do
>          get_new_values (&a, &b, &c, &n);
>      while (n <= 2 || pow (a, n) + pow (b, n) != pow (c, n));
>
b=0.  FLT requires "no solutions over the _nonzero_ integers."
Even with that correction, computer floating point is an even worse
approximation to mathematical reals than computer integers are to
mathematical ones -- and so on all systems I know of:
n = 5 or 6, a = c = 1K, b = 1

--
- David.Thompson 1 now at worldnet.att.net


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>=20
> Daniel Frey <daniel.frey@aixigo.de> wrote in message news:<3B8E019E.E48=
0504C@aixigo.de>...
>=20
> > ...
> > If someone notices he makes mistakes when he uses switch, why
> > does he use it anyway?
>=20
> [...]
>
> Ok, plan B:
>=20
> - "switch" stays like it is.

Agreed :)

> - Compilers issue a *warning* when they detect fall-through behaviour
>   in a switch (e.g. based on a missing break or return or throw).

Could be a good idea if it's optional. What I'm missing is an
opportunity to tell the compiler to enable or disable certain warnings
on certain packages. Foreign libs that where not designed with this
warning in mind will issue to much warnings in large project thus hiding
the real warnings inside their output.

> - The warning can be suppressed if fall-through is the intended
>   behaviour.

As we are talking about compilers and not the language anymore, I'd like
to see a compiler-specific extension here. Within your project, you
could add a define for 'fallthru' if you like. This keeps the language
clean and makes it clear that explicit that compiler-dependent
extensions are used. It's again the "how can I know the end is
reached"-thing. For one compiler you'll have to add 'fallthru' as it
cannot detect that a block never reaches it's end while another compiler
may be better in detecting it. I don't think there's an easy way out :)

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
> kaih=883a$rZHw-B@khms.westfalen.de (Kai Henningsen) wrote in message news:<883a$rZHw-B@khms.westfalen.de>...
>
>>clive@on-the-train.demon.co.uk (Clive D. W. Feather)  wrote on 27.08.01 in <SPrGwJIp+li7EwXM@romana.davros.org>:
>>
>>
>>>You don't even need a new keyword: "auto switch" or
>>>"switch case" or some such combination could be used.
>>>
>>"restrict switch".
>
> Why not "static switch"? "static" is over-overloaded anyway.
>
> But for a syntax that should be preferred, it should be less
> typing, even less than "switch".

Less typing than "switch" -- how about "witch" (or should
that be "which"? ;)

-- James Dennett

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0108280528.44df8ccb@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>> If you're going to do this, then it is far far better to leave *all*
>> existing code working, and introduce a new keyword "safe_switch".
>> ...
>
>Of course it would be much easier to define a syntax based on
>a statement with a new keyword. In that case it wouldn't even
>be necessary to define it in a way that it takes a break or
>something else to jump out.

Right, and you can cleanup any other problems.

>But the proposal is an attempt to do it the other way.
>Because: It is probably by far more difficult to establish
>a new programming style (e.g. with a keyword "safe_switch")
>than changing the syntax.

Not necessarily. Prototypes were introduced into C as a new syntax,
rather than changing the requirements on function definition but not
altering the syntax. People adopted them because of the advantages.

>Recommending to use a revised switch statement with another
>keyword for getting more safety into code, is like telling
>someone just to get up one hour earlier in the morning if he
>would like to have a daylight-saving time: It just doesn't
>take account of the fact that there are things that depend
>on each other.

Which means what ? You are proposing fiddling with the syntax because
some people make errors with an existing construct; you ignore the fact
that some people find that construct very useful. I'm proposing that you
create a new syntax and teach people to use it; those who need the old
construct still have it.

>Did the standardization committees issue a recommendation to
>make use of explicit int, in cases where someone would like
>to have more type safety? No.

Yes, in C90.

>Instead it was made obligatory.

The situations are hardly comparable. Implicit int does not provide any
functionality that explicit int does not; it's merely syntactic sugar.
As such, requiring the explicit int is harmless - existing code can
quickly and easily be changed and the change is trivial; it could even
be automated.

Banning a whole range of switch *semantics*, on the other hand, is much
more significant. You still haven't explained what will happen with
constructs that don't meet the special case of the controlled statement
being a compound statement and the case labels all labelling statements
that are direct elements of that compound.

>I think overcoming habits is harder than revising a standard.

Not always.

>And don't forget the documentation! With the proposal you
>wouldn't have to rewrite all programming books!

Of course you would. All the ones that say "if there's no break, it
falls through", for a start.

>Duff's Device is by the way an interesting example: I looked
>at the *original* code too, and I think the original code
>wouldn't compile, neither under standard C nor under standard
>C++ ...

Checking the copy at <http://www.lysator.liu.se/c/duffs-device.html>, I
can see absolutely nothing in the meat of it that violates C99. The code
uses implicit int and old-style declarations, but the former is trivial
to fix and the latter is legal.

Um, on second thoughts it appears to be undefined behaviour and has been
since the C Standard first came out, despite the fact that "everyone
knows" it works. But the issue involved is nothing to do with switch
statements per se.

>> Existing code is important. There is no need to change it
>> if you provide new facilities.
>
>It is important that existing code is correct. Safety is not
>a facility.

But my existing code *is* correct.

>"Existing code is important" cannot mean to leave any code
>written once upon a time just like it is and touch it under
>no circumstances no matter if it serves actual needs or not.

But it serves my needs quite well. If we're going to have two
constructs, one with the old semantics and one with the new, then the
*new* construct should have the new semantics. That's common-sense.

>An actual need that I see is taking into account that there
>are novices writing code.

So teach them to use the new construct.

>And there is an even more fundamental problem that has
>nothing to do with the market: All programmers have to
>make experiences before they are experienced programmers.

True but irrelevant.

>After all I would like to say that I don't want to get
>hysteric about problems concerning missing breaks in a
>switch. There are other problems!

Indeed.

>The chances that existing code runs under the proposals
>syntax are not so bad I think. Of course it would be
>interesting to have some statistics.

Much of my code would break. I'm sure I'm not the only one.

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0108280108.9998cd5@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>> What does 'formally reachable' mean?
>
>"Formally" is supposed to mean: based on the horizon of the
>compiler's ability to analyze if it is possible to reach a
>point or not:

But you need to define this as well.

>void example2(void)
>{
>  exit(0);
>  int i;  // compiler can *not* analyze that this point
>          // will never be reached.

Yes, it can. The function exit is part of the Standard and, therefore, a
compiler can know that it never returns. [Yes, "exit" can be a macro,
but this test would be made after preprocessing.]

>> "fall_thru" is just ugly.
>That was the purpose. The likelyhood to interfere with other
>names should be low.

There is a defined way to *ensure* that you don't interfere: use a
reserved name like "_Fall".

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

cizarre@gmx.net (Michael Andres) writes:

> IV:   There is a case-block scope: It begins at the
>       entry point of the case-block and ends at the
>       end of the case-block.

No.  That is a quiet change to this code:

        int j = 0;
        switch (i) {
            case 1:  int j;  bar(&j);  break;
            case 2:          baz(&j);  break;
        }

Currently baz(&j) uses the 2nd j, with implicit {} it will use 1st j.

I think implicit braces would be bad idea even if the new 'fall-thru
switch' got a new name (like 'auto switch') so it didn't break old code,
since the code would _look_ like it has different scope than it has.
C has a some other confusing scope rules, but nothing this blatant.

If you want every case block to have its own scope, I suggest you use
a different syntax and require the braces.  E.g.

    auto switch (i) {
 case (1) {
     int j;
     bar(&j);
     /* might just as well let break; be implicit too */
 }
 case (2) {
     baz(&j);
 }
    }

A different 'case' syntax also makes it easier to see what kind of
switch you are looking at, if you are looking at a 'case' in a big
switch.


>     case 'd':  // ...
>                for(;;)
>                  f();
>                // ok: because of "for(;;)" the end of
>                // this case-block can never be reached
>
>     case 'e':  // ...

Require a break here.  If you begin to demand flow-control
analysis from the compiler, where do you stop?
Should it figure out that this loop will never end?
 for (;;) { if (0) break; }
How about this?
 int i = 1;
 while (i) { }
or this?
 if (something) i = 3; else i = 4;
 while (i) { }

--
Hallvard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message news:<tgg0ac49to.fsf@mercury.rus.uni-stuttgart.de>...
> ...
> You have to specify this concept formally, otherwise implementations
> will differ in what they accept as valid in put

I see.

> (the C# spec contains quite a few similar flaws).

Could you give an example? I am just curious. As this is
probably out of topic you can send me a mail if you want.

 - Michael


======================================= MODERATOR'S COMMENT:
 It would be off-topic for both these groups, I suspect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Sef Campstein" <sef@campst.tmfweb.nl> wrote in message news:<9me1bm$3di$1@cyan.nl.gxn.net>...
> > VII:  A new statement with the keyword "fall_thru_switch"
> >       is introduced into the language.
> >       A fall_thru_switch statement has exactly the same
> >       syntax as the current switch statement.
> In what way can we make a distinction between the two if it
> has exactly the same syntax?

What I was trying to say was that if fall_thru_switch were
integrated in a *new* compiler version then it would behave
like the switch of an *old* compiler.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Clive D. W. Feather" <clive@on-the-train.demon.co.uk> wrote in message news:<gtEqIigWG9i7EwS1@romana.davros.org>...

> ...
> you ignore the fact that some people find that construct
> very useful.

No, I don't ignore it: The idea behind "fall_thru_switch" is
that it behaves just like the current construct. Those who
find it useful wouldn't have to change their personal programming
style.

> ...
> Implicit int does not provide any functionality that explicit int
> does not; it's merely syntactic sugar. As such, requiring the
> explicit int is harmless - existing code can quickly and easily be
> changed

But it has to be changed.

> and the change is trivial; it could even be automated.

I thought of automated conversion when I mentioned the conversion
tools in my last posting. (The most trivial kind of conversion
would be to replace the switch by fall_thru_switch.)


> >And don't forget the documentation! With the proposal you
> >wouldn't have to rewrite all programming books!
>
> Of course you would. All the ones that say "if there's no break,
> it falls through", for a start.
>

The compiler would issue an error message as soon as someone
would try to compile a fall through without the keyword "fall_thru".
Similar to a missing "int".


> >> Existing code is important. There is no need to change it
> >> if you provide new facilities.
> >
> >It is important that existing code is correct. Safety is not
> >a facility.
>
> But my existing code *is* correct.

Prove it!  :-)


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote in message news:<HBF.20010829w07i@bombur.uio.no>...
> ...
> If you want every case block to have its own scope, I suggest
> you use a different syntax and require the braces.

I agree, requiring the braces would be a better idea, because
it makes more obvious to the reader of the code what really
happens.

> ...
> If you begin to demand flow-control analysis from the compiler,
> where do you stop?
> Should it figure out that this loop will never end?
>  for (;;) { if (0) break; }
> How about this?
>  int i = 1;
>  while (i) { }
> or this?
>  if (something) i = 3; else i = 4;
>  while (i) { }

I see. Doing it based on flow-control analysis has more implications
than I thought it would have at first sight.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Hallvard B Furuseth" <h.b.furuseth@usit.uio.no
<mailto:h.b.furuseth@usit.uio.no>> wrote in message
<news:HBF.20010829w07i@bombur.uio.no>...> cizarre@gmx.net
<mailto:cizarre@gmx.net> <snip>
> If you want every case block to have its own scope, I suggest you use
> a different syntax and require the braces. E.g.
>
> auto switch (i) {
> case (1) {
> int j;
> bar(&j);
> /* might just as well let break; be implicit too */
> }
> case (2) {
> baz(&j);
> }
> }
>

And while we're at it, maybe we could also add non-constant
case expressions also, e.g.

int n = foob();
int m = boof();
auto switch (i) {
   case (n) {
      int j;
      bar(&j);
      }
   case (m) {
      baz(&j);
      }
   }

Might as well load up the new switch with all the goodies
that correct the 'sins' of the old one, but for Pete's sake,
let's get off this notion that the syntax of the old switch
be changed in such a way that it breaks old code (Hallvard,
I understand that you're not suggesting that). I'll never
use the new switch anyhow (I never went for the New Coke
either). :)

~Jeff

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0108290145.59f81085@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>> Implicit int does not provide any functionality that explicit int
>> does not; it's merely syntactic sugar. As such, requiring the
>> explicit int is harmless - existing code can quickly and easily be
>> changed
>
>But it has to be changed.

But the changed code can be used on compilers that don't implement the
new test. And the code has the same meaning on both old and new.

Your proposal involves changing the semantics in an incompatible manner.
No matter which style you want, the same code can't be used on both
"old" and "new" compilers. Since you're proposing a new construct, let
*it* have the new semantics.

>> >And don't forget the documentation! With the proposal you
>> >wouldn't have to rewrite all programming books!
>>
>> Of course you would. All the ones that say "if there's no break,
>> it falls through", for a start.
>
>The compiler would issue an error message as soon as someone
>would try to compile a fall through without the keyword "fall_thru".
>Similar to a missing "int".

You *still* need to rewrite programming books because of the changes.

>> But my existing code *is* correct.
>
>Prove it!  :-)

It matches the specification (I wrote both, so I can be sure of that).

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Michael Andres wrote:
>=20
> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> wrote in message news:<H=
BF.20010829w07i@bombur.uio.no>...
> > ...
> > If you want every case block to have its own scope, I suggest
> > you use a different syntax and require the braces.
>=20
> I agree, requiring the braces would be a better idea, because
> it makes more obvious to the reader of the code what really
> happens.
>=20
> > ...
> > If you begin to demand flow-control analysis from the compiler,
> > where do you stop?
> > Should it figure out that this loop will never end?
> >       for (;;) { if (0) break; }
> > How about this?
> >       int i =3D 1;
> >       while (i) { }
> > or this?
> >       if (something) i =3D 3; else i =3D 4;
> >       while (i) { }
>=20
> I see. Doing it based on flow-control analysis has more implications
> than I thought it would have at first sight.

I wonder if your approach is appropriate for a language like C/C++.
You'd like the provide no default behaviour for the end of a case-block,
instead, you are trying to force the user to explicitly write down what
he wants. While this may increase safety, it is IMO against the basic
structure of the language. The current switch may not be intuitive for
some people, but it is very direct in that it does what if written down
in the code. If there is a break, it is executed. If there is no break,
the program simply continues with the next statement.

Some people seem to have different expectations at the switch statement,
I guess because they think it is some kind of "if / else if / else" -
replacement. If it should turns out to be a mayority and these people
make too much mistakes (which I doubt, but anyway), there are two
options:

a) Provide a new default behaviour. No flow control analysis will be
required, just provide a 'switch' like this:

   switch( x ) {
      case 0, 1, 2:
         something();
         // No fall-through here - implicit 'break'

      case 3, 4:
         something_else();
         continue;

      case 5:
         if( some_condition() )
            continue 1;
         // No fall-through here!

      case 6, default:
         something_completely_different();
   }

The implicit-break-solution has some impacts you can see above: 'case'
can have multiple values, 'default' can be used as on of these cases,
continue accepts the case values (including 'default') and as it doesn't
make sense the old way: All blocks have their own scope for variables.
Compilers are able to remove non-reachable implicit 'break'-statements
if they can figure out it actually is non-reachable, but if they can't,
it's not a problem and there won't be incompatibilities depending on the
compilers.

b) Your solution which I'd call the explicit-break-solution. As we have
all seen it, I won't repeat it here, but some of it's drawbacks:

- Depending on the compiler's ability to analyse the reachablility of a
block's end, the code is valid or not. Defining rules to create a
standard is hard and prevents further optimizations as compiler
technologies improve.
- All programmers will have to write more code than today or with
solution a). While this can be seen as an advantage, it can also lead to
code that hides the original idea and even worse the code may be slower
(depending on the optimizations of the compiler)
- As your solution is very similar to if( ... ) { ... } else if( ... ) {
... } else if( ... ) { ... } else { ... } I wonder where's the
difference (from the safety you'd like to achive). If someone notices he
makes mistakes when he uses switch, why does he use it anyway? If I
don't understand exceptions, I shouldn't use them. (note: this shouldn't
be taken personal, it is just meant to show that you can use your own
coding style to prevent errors. I do this and I think a lot of people
will agree that it helps :)

Now, especially for the last point there is something that 'switch' can
do that cannot be achived with if/else/...: The compiler can optimize.
At least it is claimed by a lot of people, but I'd like to hear someone
who actually knows it: Does this really lead to better code or are
today's compilers clever enough to provide the same optimizations for
similar if/else/...-constructs? If they are, we can concentrate on the
interaction of the syntax and the programmer, otherwise we need to be
careful not be remove a feature from the language.

Regards, Daniel

--
Daniel Frey

aixigo AG - financial training, research and technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <HBF.20010829w07i@bombur.uio.no>, Hallvard B Furuseth
<h.b.furuseth@usit.uio.no> writes
>Should it figure out that this loop will never end?
>       for (;;) { if (0) break; }
>How about this?
>       int i = 1;
>       while (i) { }
>or this?
>       if (something) i = 3; else i = 4;
>       while (i) { }

Or this ?

     unsigned int a, b, c, n;
     do
         get_new_values (&a, &b, &c, &n);
     while (n <= 2 || pow (a, n) + pow (b, n) != pow (c, n));

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Jeff Howe" <jeffh@delorme.com> wrote in message
news:10EBCFD1BEF2D2119E2300105A98299B04337F91@china1.delorme.com...
> "Hallvard B Furuseth" <h.b.furuseth@usit.uio.no
> <mailto:h.b.furuseth@usit.uio.no>> wrote in message
> <news:HBF.20010829w07i@bombur.uio.no>...> cizarre@gmx.net
> <mailto:cizarre@gmx.net> <snip>
> > If you want every case block to have its own scope, I suggest you use
> > a different syntax and require the braces. E.g.
> >
> > auto switch (i) {
> > case (1) {
> > int j;
> > bar(&j);
> > /* might just as well let break; be implicit too */
> > }
> > case (2) {
> > baz(&j);
> > }
> > }
> >
>
> And while we're at it, maybe we could also add non-constant
> case expressions also, e.g.
>
> int n = foob();
> int m = boof();
> auto switch (i) {
>    case (n) {
>       int j;
>       bar(&j);
>       }
>    case (m) {
>       baz(&j);
>       }
>    }

if you do that it will be harder for the compiler to optimise the generated
machine code because it won't know the range of values (eg. using a jump
table). If you want to do this why not use an if/else statement. that is
what it is there for.

Ray.

> Might as well load up the new switch with all the goodies
> that correct the 'sins' of the old one, but for Pete's sake,
> let's get off this notion that the syntax of the old switch
> be changed in such a way that it breaks old code (Hallvard,
> I understand that you're not suggesting that). I'll never
> use the new switch anyhow (I never went for the New Coke
> either). :)
>
> ~Jeff


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Considering the postings to this thread I have
written a second version of the proposal:


-- Proposal for an improved switch (2nd version) --

- Content:

A typical programming error in conjunction with
the switch statement is an unintentionally missing
break which makes the program run into the next
case label.

This is a proposal for a new syntax that has the
purpose to avoid the error.

The intention of this proposal is *not* to provide
new features for enhanced programming techniques,
instead it focusses on improving the *correctness*
of code that makes use of the switch statement.


- Objectives for the changed syntax:

 a:   The proposed new syntax should be less
      error prone than the current one.
 b:   Most of the existing code should run without
      change.
 c:   Everything that can be coded with the current
      syntax must still be possible with the proposed
      new syntax, though it might be necessary to
      make some modifications on the code in order
      to achieve the same effect.
 d:   Required changes should not be expensive.
      It is not desirable to rewrite too much of
      the code. Extensive tests of the modified
      code should not be necessary.



- Changes:

  The syntax of the current switch statement is
  intended to be replaced by the syntax explained
  in the following items.


I:    A switch statement consists of a list of
      "case-blocks".
      Each case-block starts with one or more
      case-block-labels.
      A case-block-label can be either:
          - keyword "case" followed by a
            constant-expression followed by a colon
      or: - keyword "default" followed by a colon
      There can be one or no "default"-label.
      [Remark: A similar switch syntax is defined
      in C#.]


II:   The end of a case-block must be formally not
      reachable: It leads to a compiler error if
      the end of a case-block can be formally reached.


III:  Item (II) is not being applied to the last
      case-block in a switch.
      [Remark: This exception helps keeping existing
      code compilable.
      Without this exception the syntax would be
      more regular, but the chances that existing
      code would compile without any change would
      be much lower without this.
      This exception might be dropped in future
      revisions. Therefore it is considered to be
      good style to write the code as if this
      exception wouldn't exist. Compiler manufacturers
      are encouraged to make the compiler issue a
      warning if the condition of item (II) is not
      fulfilled in the last case-block.]


IV:   There is a case-block scope: It begins at the
      entry point of the case-block and ends at the
      end of the case-block.
      [Remark: That means, with the proposed syntax
          case 'a':    int i = 1;
                       break;
          case 'b':    break;
       is identical to
          case 'a':  { int i = 1;
                       break;
                     }
          case 'b':  { break; }
      For the current switch syntax there is no such
      thing like a case-block scope. Therefore the lines
          case 'a':    int i = 2;
                       break;
          case 'b':    break; // error
      wouldn't compile. This can be confusing. On the other hand
          case 'b':    break;
          case 'a':    int i = 2;
                       break; // ok
      compiles without error, which demonstrates a dependency
      on the order of code that might be unintended.
      The lines
          case 'c':    int i;
                       // ...
                       break;
          case 'd':    int i; // error
                       // ...
                       break;
      wouldn't compile according to the current switch
      syntax neither.
      In contrast to the current syntax, the proposed
      switch syntax eliminates the dependency on the
      order of code and introduces a more local
      behaviour.
      All of the above examples would compile with
      the proposed switch syntax.]


V:    A fall-through-statement is introduced. It consists
      just of the keyword "fall_thru" and behaves like a
      goto to the entry point of the next following
      case-block.
      A fall_thru can only be used within a case-block.
      If fall_thru appears in the statement-list of a
      case-block, then it must be the last statement in
      the list.
      A fall-through-statement does not affect the
      case-block scope.
      [Remark: With fall_thru the programmers intention
      is "documented by code".]


VI:   A fall_thru can be used at the end of the last
      case-block as well, where it has just the effect
      to leave the switch.
      [Remark: As the switch would be left at the end
      of the last case-block anyway, the fall_thru
      would be redundant, just like a break in the last
      case-block is redundant.
      The rational behind this is to simplify automatic
      code generation.]


VII:  A new statement with the keyword "fall_thru_switch"
      is introduced into the language.
      A fall_thru_switch statement has exactly the same
      syntax as the current switch statement.
      [Remark: fall_thru_switch is introduced because
      there are some special coding techniques to which
      the proposed switch syntax cannot be applied.
      Furthermore fall_thru_switch can simplify adjustments
      of existing code to the proposed syntax, though
      the switch statement should always be first choice,
      if applicable.]




- Impact of the changes:



Example 1:
  switch (c) {
    case 'a':  // ...
               break;  // ok

    case 'b':  // ...
               throw exception_x();
               // ok, because the end of this case-block
               // cannot be reached

    case 'c':  // ...
               return; // ok

    case 'd':  // ...
               for(;;)
                 f();
               // ok: because of "for(;;)" the end of
               // this case-block can never be reached

    case 'e':  // ...
               goto label_x;
               // ok, because end cannot be reached

    case 'f':  // ...
               fall_thru; // works like a goto
               // ok, because end cannot be reached

    default :  // ...
               break;
  }
  label_x: // ...




Example 2:
  int i = 0;
  switch (c) {
    case 'a':  ++i;
               // error because end of this case-block
               // *can* be reached

    case 'b':  ++i;
               break;
               // ok because end of this case-block
               // can *not* be reached

    case 'c':  ++i;
               // ok because last case-block (see
               // item (III))
               // But it is regarded to be better
               // style to use a "break" here
               // too (see remark to item (III)).
  }




Example 3:
  int i = 0;
  switch (c) {
    case 'a':  ++i;
               fall_thru; // works like a goto to the entry
                          // point of the following case-block
    case 'b':  ++i;  //
               fall_thru; // works like a goto to the end of
                          // the switch statement
  }
  // at this point: i==2 if c=='a',  i==1 if c=='b',
  // i==0 in all other cases




  Conforming to item (V) fall_thru has to be the
  last statement in a statement-list of a case-block
  if fall_thru appears in that list.
  For that reason the following is illegal:

Example 4:
  switch (c) {
    case 'd':  fall_thru;   // illegal
               break;

    case 'e':  // ...
               if (condition_x)
                 fall_thru; // illegal because fall_thru is not the
                            // last statement in the case-block
                            // statement-list
                            // (in this case the if-statement is
                            // the last one!)
    case 'f':  // ...
               break;
  }




Example 5:
  switch (c) {
    case 'g':  exit();
               // exit() belongs to the standard but not
               // to the language itself. That's why the
               // end of this case-block is formally
               // reached => error
               //
               // This would break existing code but the
               // error could be detected at compile time!

    case 'h':  exit();
               break; // ok

    case 'i':  // ...
               break;
  }





 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

cizarre@gmx.net (Michael Andres) writes:

> I:    A switch statement consists of a list of
>       "case-blocks".
>       Each case-block starts with one or more
>       case-block-labels.
>       A case-block-label can be either:
>           - keyword "case" followed by a
>             constant-expression followed by a colon
>       or: - keyword "default" followed by a colon
>       There can be one or no "default"-label.
>       [Remark: A similar switch syntax is defined
>       in C#.]

Could you provide a more formal description of the syntax?


> II:   The end of a case-block must be formally not
>       reachable: It leads to a compiler error if
>       the end of a case-block can be formally reached.

What does 'formally reachable' mean?  Please specify.  AFAIK, both the
C and C++ standards do not define this term.

> V:    A fall-through-statement is introduced. It consists
>       just of the keyword "fall_thru" and behaves like a
>       goto to the entry point of the next following
>       case-block.

"fall_thru" is just ugly.

>       A fall-through-statement does not affect the
>       case-block scope.

What does that mean?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <8fbd32b9.0108261552.7530c3d6@posting.google.com>, Michael
Andres <cizarre@gmx.net> writes
>-- Proposal for an improved switch (2nd version) --

>VII:  A new statement with the keyword "fall_thru_switch"
>      is introduced into the language.
>      A fall_thru_switch statement has exactly the same
>      syntax as the current switch statement.

If you're going to do this, then it is far far better to leave *all*
existing code working, and introduce a new keyword "safe_switch". This
can then have cleaner (in your view, anyway) semantics. Anyone who wants
the new semantics can then just go:
     #define switch safe_switch

You don't even need a new keyword: "auto switch" or "switch case" or
some such combination could be used.

> c:   Everything that can be coded with the current
>      syntax must still be possible with the proposed
>      new syntax, though it might be necessary to
>      make some modifications on the code in order
>      to achieve the same effect.

Existing code is important. There is no need to change it if you provide
new facilities.

>I:    A switch statement consists of a list of
>      "case-blocks".
[...]
>II:   The end of a case-block must be formally not
>      reachable: It leads to a compiler error if
>      the end of a case-block can be formally reached.

Better proposal: since we have a new keyword for these new kinds of
switches, require the block to end with "endcase" or "case break" or
something like that. Then "break" can revert to its meaning of "exit the
innermost loop". You could also do what BCPL does, and allow endcase to
be an action within a case body.

Or find a punctuator that means "gap between case-blocks". "..." comes
to mind. Reaching the end of a case-block means the end of that case
(this is how Algol 68 does it).

That is, the syntax is:

     auto-switch:    auto switch ( expression ) { case-block-set }

     case-block-set: case-block
                     case-block-set ... case-block

     case-block:     case-label-set block-item-list

     case-label-set: case-label
                     case-label-set case-label

     case-label:     case expression :
                     default :

(block-item-list is defined already in C99). Constraint: there shall not
be a case-label within a case-block's block-item-list except within an
inner switch or auto-switch statement.

>III:  Item (II) is not being applied to the last
>      case-block in a switch.

Not necessary in a new construct.

>IV:   There is a case-block scope: It begins at the
>      entry point of the case-block and ends at the
>      end of the case-block.

In the new construct this would be reasonable.

>      For the current switch syntax there is no such
>      thing like a case-block scope. Therefore the lines
>          case 'a':    int i = 2;
>                       break;
>          case 'b':    break; // error
>      wouldn't compile.

On the contrary, it is legal C99.

>V:    A fall-through-statement is introduced. It consists
>      just of the keyword "fall_thru" and behaves like a
>      goto to the entry point of the next following
>      case-block.

In a new "safe switch", labels and jumps are a better idea.

--
Clive D.W. Feather, writing for himself  | Home: <clive@davros.org>
Tel: +44 20 8371 1138 (work)             | Web:  <http://www.davros.org>
Fax: +44 20 8371 4037 (D-fax)            | Work: <clive@demon.net>
Written on my laptop; please observe the Reply-To address

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> A typical programming error in conjunction with
> the switch statement is an unintentionally missing
> break which makes the program run into the next
> case label.
>

If you're finding this to be a problem for your projects, why not consider a
tool such as Lint? It will warn about this, along with many other possible
problems.

--
- Wilka

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> VII:  A new statement with the keyword "fall_thru_switch"
>       is introduced into the language.
>       A fall_thru_switch statement has exactly the same
>       syntax as the current switch statement.
In what way can we make a distinction between the two if it has exactly the
same syntax?


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE> wrote in message news:<tgheut8t8o.fsf@mercury.rus.uni-stuttgart.de>...
> cizarre@gmx.net (Michael Andres) writes:
>
> > I:    A switch statement consists of a list of
> >       "case-blocks".
> >       Each case-block starts with one or more
> >       case-block-labels.
> >       A case-block-label can be either:
> >           - keyword "case" followed by a
> >             constant-expression followed by a colon
> >       or: - keyword "default" followed by a colon
> >       There can be one or no "default"-label.
> >       [Remark: A similar switch syntax is defined
> >       in C#.]
>
> Could you provide a more formal description of the syntax?

The given description is not only not very formal, it is also
incomplete. Would you like to write a parser for it? We might
then elaborate the details together.


> > II:   The end of a case-block must be formally not
> >       reachable: It leads to a compiler error if
> >       the end of a case-block can be formally reached.
>
> What does 'formally reachable' mean?

"Formally" is supposed to mean: based on the horizon of the
compiler's ability to analyze if it is possible to reach a
point or not:

void example1(void)
{
  return;
  int i;  // compiler can analyze that this point will
          // never be reached
  i = 0;
}


void example2(void)
{
  exit(0);
  int i;  // compiler can *not* analyze that this point
          // will never be reached.
          // so, this point is *formally* reachable although
          // it will never be reached in the program.
  i = 0;
}


> > V:    A fall-through-statement is introduced. It consists
> >       just of the keyword "fall_thru" and behaves like a
> >       goto to the entry point of the next following
> >       case-block.
>
> "fall_thru" is just ugly.
>

That was the purpose. The likelyhood to interfere with other
names should be low.


> >       A fall-through-statement does not affect the
> >       case-block scope.
>
> What does that mean?
>

Contrary to the proposed syntax there is no "case-block scope" in
the current syntax. I wanted to emphasize that the existence of
a "fall_thru" within a case-block doesn't mean that the scope rules
suddenly behave just like in the current syntax.


 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

cizarre@gmx.net (Michael Andres) writes:

> > Could you provide a more formal description of the syntax?
>
> The given description is not only not very formal, it is also
> incomplete. Would you like to write a parser for it?

No, I just want to see the syntax.

> > What does 'formally reachable' mean?
>
> "Formally" is supposed to mean: based on the horizon of the
> compiler's ability to analyze if it is possible to reach a
> point or not:

[examples snipped]

You have to specify this concept formally, otherwise implementations
will differ in what they accept as valid in put (the C# spec contains
quite a few similar flaws).  For example, quit a few compilers know
that exit() and longjmp() do not return.

--
Florian Weimer                    Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Clive D. W. Feather" <clive@on-the-train.demon.co.uk> wrote in message news:<SPrGwJIp+li7EwXM@romana.davros.org>...
> In article <8fbd32b9.0108261552.7530c3d6@posting.google.com>, Michael
> Andres <cizarre@gmx.net> writes
> >-- Proposal for an improved switch (2nd version) --
>
> >VII:  A new statement with the keyword "fall_thru_switch"
> >      is introduced into the language.
> >      A fall_thru_switch statement has exactly the same
> >      syntax as the current switch statement.
>
> If you're going to do this, then it is far far better to leave *all*
> existing code working, and introduce a new keyword "safe_switch".
> ...

Of course it would be much easier to define a syntax based on
a statement with a new keyword. In that case it wouldn't even
be necessary to define it in a way that it takes a break or
something else to jump out.

But the proposal is an attempt to do it the other way.
Because: It is probably by far more difficult to establish
a new programming style (e.g. with a keyword "safe_switch")
than changing the syntax.

Recommending to use a revised switch statement with another
keyword for getting more safety into code, is like telling
someone just to get up one hour earlier in the morning if he
would like to have a daylight-saving time: It just doesn't
take account of the fact that there are things that depend
on each other.

Did the standardization committees issue a recommendation to
make use of explicit int, in cases where someone would like
to have more type safety? No. Instead it was made obligatory.

I think overcoming habits is harder than revising a standard.

And don't forget the documentation! With the proposal you
wouldn't have to rewrite all programming books! Remember you
told me about the coding example of Duff's Device? I found it
finally in an exercise of chapter "expressions and statements"
in Stroustrup's book.

Besides that example there is only one more which wouldn't
compile - it's an example for the fall through behaviour of
switch, together with a recommendation that it would be a
good idea to make a comment if fall through behaviour is
intended. Could there be a better "comment" than writing
fall_thru into the code?

All other examples would conform to the proposed syntax and
compile without error (provided I have not missed any example
in the book).
It would be interesting to check out K&R (ANSI) for this too.

Duff's Device is by the way an interesting example: I looked
at the *original* code too, and I think the original code
wouldn't compile, neither under standard C nor under standard
C++ ...


> Anyone who wants the new semantics can then just go:
>      #define switch safe_switch

You will then certainly agree that it would be not more
effort to write
       #define switch fall_thru_switch
for getting instant backwards compatibility.  :-)

(I wouldn't really recommend that. It should always be more
uncomfortable to use an unsafe version of something. And
writing down the ugly word fall_thru_switch *is* uncomfortable.)


> Existing code is important. There is no need to change it
> if you provide new facilities.

It is important that existing code is correct. Safety is not
a facility.

"Existing code is important" cannot mean to leave any code
written once upon a time just like it is and touch it under
no circumstances no matter if it serves actual needs or not.

And if it is not compatible: What about conversion tools?

An actual need that I see is taking into account that there
are novices writing code. Look at the market: You do not
always have the choice to say you would like to hire
experienced programmers only.

And there is an even more fundamental problem that has
nothing to do with the market: All programmers have to
make experiences before they are experienced programmers.


After all I would like to say that I don't want to get
hysteric about problems concerning missing breaks in a
switch. There are other problems!

But I don't agree with some argumentation. We got to
solve real world issues with a programming language.

Taking into account that there are always novices coding
programs *is* a real world issue.

The chances that existing code runs under the proposals
syntax are not so bad I think. Of course it would be
interesting to have some statistics.


I have already thought about another solution which
would look like

#pragma switch_off_real_world

but I don't like pragmas.



 - Michael

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]