"Daniel Frey" <daniel.frey@aixigo.de> wrote

>You cannot assume that it's obvious whether there is code between two
labels or not. Think of MACROS or #ifdef.

Well, IMHO that is a broken case anyway, I'd not bring that in the discussion. :)  Having an ifdef like that ypu'd definitely need the #else part with explicit handler in the other case. Or you'll have the

>One possible solution might be:
>   case 'x', 'X', 'y', 'Y':

That's cool. Having that I'd be quite happy. Even more if I also could use ranges there, say

case 27, 'a' .. 'z', 'A' .. 'Z':

(the syntax to describe a renge might be different).

But sometimes it's benefical to use distinct lines for the cases even having that. Either to provide intuitively fitting comments, or to handle those #ifdef cases. The real ones, when you make state-mahines with different behavior depending on build (say, having   a single source for the server and client side of the protocol).

The best solution wolud be a new keyword for 'switch'. Inside that newcase every case label has an implicit break before it. The old one works as it did. No existing code broken. Everyone can start using the new keyword. (The risk-lovers could even #define case to newcase, the others could replace it in-place after checking the actual code.)

Paul

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

>If I were designing a language from scratch, of course, the
>switch would be made to work correctly, with each case being a lexical
>block, and no fall through.

The interesting thing is, we have good and benign fall-through cases most people seemengly not even notice as the case.

switch(inchar)
{
    case 'a':
        {
            // stuff
        }
        break;

    case 'b':
        {
            // stuff
        }
        // break; // fall through to c!
    case 'c':
        {
            // stuff
        }
        break;

    case 'x':    ***
    case 'X':   ***
    case 'y':    ***
    case 'Y':
        {
            // stuff
        }
        break;
}

At places marked *** a fall-through actually happens to the next label. And it's assumed as the self-evident case, no comment or anything needed. A redesigned case should probably keep that simple case of fallthrough, having the implicit break only when there is something between case labels.

Paul

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <3cfd1a8f@andromeda.datanet.hu>, Balog Pal <pasa@lib.hu>
writes
>The interesting thing is, we have good and benign fall-through cases most people seemengly not even notice as the case.
>
>switch(inchar)
>{
>    case 'a':
>        {
>            // stuff
>        }
>        break;
>
>    case 'b':
>        {
>            // stuff
>        }
>        // break; // fall through to c!
>    case 'c':
>        {
>            // stuff
>        }
>        break;
>
>    case 'x':    ***
>    case 'X':   ***
>    case 'y':    ***
>    case 'Y':
>        {
>            // stuff
>        }
>        break;
>}
>
>At places marked *** a fall-through actually happens to the next label. And it's assumed as the self-evident case, no comment or anything needed.
>A redesigned case should probably keep that simple case of fallthrough, having the implicit break only when there is something between case
>labels.

Well if you were to redesign a selection mechanism why not do it
properly and allow such things as
case X,Y,x,y :

And if we are going to mess with this why not have a 'for' that is
applied to a comma separated list such as:
for(int i = {1,4,7,11}) do something



--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Balog Pal wrote:
>=20
> >If I were designing a language from scratch, of course, the
> >switch would be made to work correctly, with each case being a lexical
> >block, and no fall through.
>=20
> The interesting thing is, we have good and benign fall-through cases mo=
st people seemengly not even notice as the case.
>=20
> switch(inchar)
> {
>     case 'a':
>         {
>             // stuff
>         }
>         break;
>=20
>     case 'b':
>         {
>             // stuff
>         }
>         // break; // fall through to c!
>     case 'c':
>         {
>             // stuff
>         }
>         break;
>=20
>     case 'x':    ***
>     case 'X':   ***
>     case 'y':    ***
>     case 'Y':
>         {
>             // stuff
>         }
>         break;
> }
>=20
> At places marked *** a fall-through actually happens to the next label.=
 And it's assumed as the self-evident case, no comment or anything needed=
. A redesigned case should probably keep that simple case of fallthrough,=
 having the implicit break only when there is something between case labe=
ls.

You cannot assume that it's obvious whether there is code between two
labels or not. Think of MACROS or #ifdef. With a MACRO that only
generates code in a debug version, you code works fine but the
release-version magically crashes as it now falls through. One possible
solution might be:

switch( inChar ) {
   ...
   case 'x', 'X', 'y', 'Y':
      // stuff
   ...
}

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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
>=20
> Well if you were to redesign a selection mechanism why not do it
> properly and allow such things as
> case X,Y,x,y :

See my other post written 5 seconds before I read yours... :)

> And if we are going to mess with this why not have a 'for' that is
> applied to a comma separated list such as:
> for(int i =3D {1,4,7,11}) do something

Cool idea. And why not:

  enum Foo { IS, THIS, A, GOOD, IDEA };

  for( Foo f =3D Foo ) { ... }

as a shortcut for

  for( Foo f =3D { IS, THIS, A, GOOD, IDEA } ) { ... }

It is far better to maintain if you just say "iterate all Foo's" with
your code instead of "iterate *these* Foo's: A, B, C, ...". Well, there
are also some problems: Does it enumerates the values or the
identifiers? Think of

  enum Foo { THIS =3D 1, IS =3D 0, A, GOOD, IDEA =3D GOOD };

Maybe 'for' is not the right keyword here, as it is a different thing,
but I don't have a better one at hand.

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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <23b84d65.0205291744.1622f31c@posting.google.com>, Allan W
<Allan_W@my-dejanews.com> writes
>But code like this:
>    if        (colorBlack  ==color) {
>       // Do something
>    } else if (colorBrown  ==color) {
>       // Do something
>    } else if (colorRed    ==color) {
>       // Do something
>    } else if (colorOrange ==color) {
>       // Do something
>    } else if (colorYellow ==color) {
>       // Do something
>    } else if (colorGreen  ==color) {
>       // Do something
>    } else {
>       // Handle default case
>    }
>
>Technically this is nested very deeply, but realistically the nesting
>level might as well be 1 -- it's very unlikely to have hidden traps.

except all those 'do somethings' often themselves have non-linear code
which obscures the outer selection process. When I see 'switch' I know
to look for case and break.

This also applies to the compiler, where it is easier to implement jump
tables (both direct and indirect) for switch statements because the
programmer can easily express the intent of the structure.




--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow <francis.glassborow@ntlworld.com> wrote
> Read Safer C by Les Hatton. It is well documented there. Nested if
> statements are very bad news in so far as defect rates are concerned
> (whatever language you are writing code in)

It sounds like you're talking about nested if in general, as opposed
to the equivalent of switch/case.

Surely, code like this:
    if (a<(b+5) && c[12].member=='Y') {
        if (a<b) {
            if (c[a].member==c[12].member) {
                // Do something
            } else if (c[a].member<c[12].member)
                // Do something
            } else
                // Do something
        } else {
            if (a<b) {
                throw "Logic error";
            } else {
                // Do something
            }
    }
is error prone... in fact, the code above probably does have an error
(missing left brace on line 5, or else improper indentation on lines
7 through 14).

But code like this:
    if        (colorBlack  ==color) {
       // Do something
    } else if (colorBrown  ==color) {
       // Do something
    } else if (colorRed    ==color) {
       // Do something
    } else if (colorOrange ==color) {
       // Do something
    } else if (colorYellow ==color) {
       // Do something
    } else if (colorGreen  ==color) {
       // Do something
    } else {
       // Handle default case
    }

Technically this is nested very deeply, but realistically the nesting
level might as well be 1 -- it's very unlikely to have hidden traps.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote...
>
> Read Safer C by Les Hatton. It is well documented there. Nested if
> statements are very bad news in so far as defect rates are concerned
> (whatever language you are writing code in)

I had a look last night, but couldn't see anything. Actually I was
surprised by how little numerical evidence there was to relate actual
bug rates to the kinds of "mis-uses" that he was measuring. I don't
doubt the link, and I'm sure that readability must have influenced
the author's choice of content, but it was strange to re-read a book
and discover that it didn't contain quite the hard evidence that
I'd supposed.

Also, I couldn't find any distinction between complicated "if" usage
and the if..elseif pattern that could be compared to a switch. I think
it is unfair to tar the latter with the bugs that arise from the former.
If I write a for loop and modify the loop variable in the body of the
loop then I'd expect a comparitively high bug rate. That doesn't mean
that for loops are a dangerously unstructured feature.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1022573304.1366.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>Also, I couldn't find any distinction between complicated "if" usage
>and the if..elseif pattern that could be compared to a switch. I think
>it is unfair to tar the latter with the bugs that arise from the former.
>If I write a for loop and modify the loop variable in the body of the
>loop then I'd expect a comparitively high bug rate. That doesn't mean
>that for loops are a dangerously unstructured feature.

I was thinking about 3.2.1  Control and structural complexity, and in
particular the last paragraph of that section. Granted that he does not
publish any evidence, so I guess I must also be remembering more recent
discussions I have had with the author.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:

|>  The only reason I can see to retain "switch" is that it gives the
|>  old lags a chance to talk about Duff's Device every so often.

I'd argue for readability as well.  If I were designing a language
from scratch, it would certainly have a multiway if, something like
switch.  If I were designing a language from scratch, of course, the
switch would be made to work correctly, with each case being a lexical
block, and no fall through.  But I can live with the current C++
switch, and I don't think it worth the effort to add another one
(e.g. select, or whatever).

--=20
James Kanze                                mailto:kanze@gabi-soft.de
Conseils en informatique orient=E9e objet/
                    Beratung in objektorientierter Datenverarbeitung
Ziegelh=FCttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote...
>
> Yes, but the evidence I have seen suggests that programmers make more
> errors when using if...else if... constructs.

I'm surprised, but I accept that this would be a good reason to retain,
or even enhance, switch statements.

To argue against myself for a moment, it is true that a compiler can
warn about fall-through, scoping errors and other switch-related
oversights, but if...elseif constructs are more flexible and therefore
it is harder to judge when the programmer "probably didn't mean that".

Going back to my original position, a simple measurement of error
rates in "if...elseif" constructions will necessarily include problems
that are too complicated to express as a switch.

What have you seen measured, and how great was the difference?


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1022230421.22513.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote...
>>
>> Yes, but the evidence I have seen suggests that programmers make more
>> errors when using if...else if... constructs.
>
>I'm surprised, but I accept that this would be a good reason to retain,
>or even enhance, switch statements.
>
>To argue against myself for a moment, it is true that a compiler can
>warn about fall-through, scoping errors and other switch-related
>oversights, but if...elseif constructs are more flexible and therefore
>it is harder to judge when the programmer "probably didn't mean that".
>
>Going back to my original position, a simple measurement of error
>rates in "if...elseif" constructions will necessarily include problems
>that are too complicated to express as a switch.
>
>What have you seen measured, and how great was the difference?

Read Safer C by Les Hatton. It is well documented there. Nested if
statements are very bad news in so far as defect rates are concerned
(whatever language you are writing code in)


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

> >However, even if the range of case values is contiguous, we need
> >to check that the switch parameter is within that range, which
> >costs a couple of comparisons. Furthermore, it is possible for a
> >compiler to recognise the "else if" pattern and turn it into a
> >jump table if it wants to.
>
> Yes, but the evidence I have seen suggests that programmers make more
> errors when using if...else if... constructs.

Hmmm one error I run into when using large if-elses that is caught
automatically by a switch statement is repeating the same condition at more
than one place in the if-else chain. I guess a compiler could check for such
things but mine (BCB) obviously doesn't :-)

This happens most often when theres a large if-else chain that goes
through lot of maintenance so whenever you make changes to it it's in
a hurry fixing something. Ok granted this doesn't happen to me in my
original code because I generally consider long if-else chains to be s
sign of a bad design (a virtual table lookup is just as efficient sa my
if-else chain isn't it?) and manage to avoid, but there's a lot of legacy
ones I keep runnig into.

Jurko


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

"David Schwartz" <davids@webmaster.com> wrote...
>
> IMO, any extenstion of 'switch' makes things worse. It should simply be
> deprecated in any but cases involving simple integers or enumerated
> values.

Why not just deprecate it, period?

Most style guides surely advise against it, or require an explicit
comment every time you actually want that dreadful fall-through.
Presumably those who teach C++ (or C) try to discourage its use.

I know, a switch statement can map to a jump table implementation
and that is smaller and faster than a naive translation of the
if/else-if/.../else alternative.

However, even if the range of case values is contiguous, we need
to check that the switch parameter is within that range, which
costs a couple of comparisons. Furthermore, it is possible for a
compiler to recognise the "else if" pattern and turn it into a
jump table if it wants to.

The only reason I can see to retain "switch" is that it gives the
old lags a chance to talk about Duff's Device every so often.


---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1022144964.13994.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
Hagan <K.Hagan@thermoteknix.co.uk> writes
>However, even if the range of case values is contiguous, we need
>to check that the switch parameter is within that range, which
>costs a couple of comparisons. Furthermore, it is possible for a
>compiler to recognise the "else if" pattern and turn it into a
>jump table if it wants to.

Yes, but the evidence I have seen suggests that programmers make more
errors when using if...else if... constructs.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:

> In article <1022144964.13994.0.nnrp-14.3e31ffea@news.demon.co.uk>, Ken
> Hagan <K.Hagan@thermoteknix.co.uk> writes
>>However, even if the range of case values is contiguous, we need
>>to check that the switch parameter is within that range, which
>>costs a couple of comparisons. Furthermore, it is possible for a
>>compiler to recognise the "else if" pattern and turn it into a
>>jump table if it wants to.
>
> Yes, but the evidence I have seen suggests that programmers make more
> errors when using if...else if... constructs.
>
>

If all it takes is a little evidence that the language behavior leads to
error prone programs, I've got several area's in the standard I would like
to point out that should be amended (specifically related to invalid
iterators, and strings being assigned 0).  It might make Scott Meyer's job
a little harder, but I'm not sure that would be such a bad thing (what if
his next book had to be Effective C++0x, 10 specific items to improve your
programming, and 75 things you no longer need to worry about getting wrong
:)
--
Brad Settlemyer
http://deepcopy.org/
Progamming in the trenches

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]