OddesE wrote:

> Pascal also implies a break after each case and it works like a charm. Are there any languages that don't imply a break after a case except for C/C++? What about Java?

Korn shell scripting uses fallthrough...I don't know about Bash.

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

"Sean L. Palmer" <spalmer@iname.com> wrote in message news:a552t1$1g0$1@digitaldaemon.com...
> The code generator can easily tell that the only exit from a block is to another block, and move that block's code just before the one it goto's
to,
> and eliminate the goto completely.  This doesn't go away if you hide it behind voodoo "break" syntax either... you still can get cases where more than one case wants to fallthrough to another case.  C doesn't handle that any better.  To someone unfamiliar with C, the lexical adjacency doesn't help them understand what's going on any better.  At least the goto is fairly obvious to a newbie.  Any modern optimizing compiler won't have
much
> trouble with it, although a homegrown compiler may generate suboptimal
code
> for it (it's gonna have worse problems than this though)

I just want to emphasize again that the D optimizer converts everything into goto's, and then analyzes the code as a graph of basic blocks connected by edges (goto's). You can create a nightmarish rat's nest of goto's and the optimizer will work just fine on it. All the obvious optimizations like eliminating fallthrough goto's, goto's to goto's, at nauseum, are done.

In other words, the use of goto's is not an issue for code optimization and generation with this compiler.

On Fri, 22 Feb 2002 01:36:02 -0800, "Sean L. Palmer" <spalmer@iname.com> wrote:
> Try rewriting this as a switch statement (without ranges) sometime:
> 
> char c;
> if (c >= 'A' && c <= 'Z')
> {
>   printf("uppercase");
> }
> else if (c >= 'a' && c <= 'z')
> {
>   printf("lowercase");
> }
> 
> Fingers tired yet?
> 
> Even though in this case a 256-byte table wouldn't be that bad of a way to generate the code, if you're only interested in speed.
> 
> Sometimes ranges can be a big time saver for the programmer.  Also easier to maintain if used properly.
> 
> Sean
> 
I notice you 'naturally' specify ranges by naming their end elements.
Why one would ever do this as:
    if (c>='A'  && c < '[' ) {   ...
is beyond me.

Karl

"Karl Bochert" <kbochert@ix.netcom.com> wrote in message news:1103_1014441037@bose...
> On Fri, 22 Feb 2002 01:36:02 -0800, "Sean L. Palmer" <spalmer@iname.com>
wrote:
> > Try rewriting this as a switch statement (without ranges) sometime:
> >
> > char c;
> > if (c >= 'A' && c <= 'Z')
> > {
> >   printf("uppercase");
> > }
> > else if (c >= 'a' && c <= 'z')
> > {
> >   printf("lowercase");
> > }
> >
> > Fingers tired yet?
> >
> > Even though in this case a 256-byte table wouldn't be that bad of a way
to
> > generate the code, if you're only interested in speed.
> >
> > Sometimes ranges can be a big time saver for the programmer.  Also
easier to
> > maintain if used properly.
> >
> > Sean
> >
> I notice you 'naturally' specify ranges by naming their end elements.
> Why one would ever do this as:
>     if (c>='A'  && c < '[' ) {   ...
> is beyond me.
>
> Karl

Yeah... I despise end-exclusive syntax.  It Just Ain't Natural.  I've gotten used to it in for loops but that's a special case.

Sean

The Keyword "next" if not used to end the "for" statement would be a good keyword to use to fall through.

Block typing requires that for be ended with a keyword that is unique to the for/next construct

Pavel Minayev <evilone@omen.ru> wrote in message news:a55g9r$7g8$1@digitaldaemon.com...
> "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a552t1$1g0$1@digitaldaemon.com...
>
> > Someone already suggested "goto case" and "fallthrough".  Either one is fine.  Just don't use continue or break.
>
> What about "next"?

Cases aren't enumerated.  Would you also use next "a".  If the param after
the next isn't a constant
then the compiler can not make the choice until runtime.

In that case, goto <anything> must necessarily cause a jump to the beginning of the case statement.

Not Good

Martin York <Martin.York@veritas.com> wrote in message news:a55o6t$bjh$1@digitaldaemon.com...
>
> Extending the next idea.
>
> how about
>
> switch(foo)
> {
>     case 1:
>     {//  Some stuff
>         next;                    // With just a next fall through to the
> next case
>     }
>     case 2:
>     {// Case 2 code
>         next 4;                // With an argument goto the specified
case.
> NB argument must be same type as foo.
>     }
>     case 3:
>     {// Case 3 stuff
>         next 4;
>     }
>     case 4:
>     {// Case 4 stuff.
>     }// implied break
> }
>
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:a55g80$7fq$1@digitaldaemon.com...
> > "Sean L. Palmer" <spalmer@iname.com> wrote in message news:a552t1$1g0$1@digitaldaemon.com...
> >
> > > Someone already suggested "goto case" and "fallthrough".  Either one
is
> > > fine.  Just don't use continue or break.
> >
> > What about "next"?
> >
> > select (foo)
> > {
> >     case (1)
> >     {
> >         ...
> >         next;    // fallthru
> >     }
> >     case (2)
> >     {
> >         ...
> >         next;    // fallthru
> >     }
> >     case (3)
> >     {
> >         ...      // NO fallthru
> >     }
> > }
> >
> >
>
>

Conceptually the language should be designed so that the compiler may convert a series of case statements to a standard dispatch table.

In cases where the argument is a numeric progression a long series of nested jumps can be replaced with one subtraction followed by a single indexed jump or call.

Vastly superior.

Walter <walter@digitalmars.com> wrote in message news:a56tc5$1534$3@digitaldaemon.com...
> I just want to emphasize again that the D optimizer converts everything
into
> goto's, and then analyzes the code as a graph of basic blocks connected by edges (goto's). You can create a nightmarish rat's nest of goto's and the optimizer will work just fine on it. All the obvious optimizations like eliminating fallthrough goto's, goto's to goto's, at nauseum, are done.
>
> In other words, the use of goto's is not an issue for code optimization
and
> generation with this compiler.
>
>