D vs C++

Jonathan M Davis jmdavisProg at gmx.com
Sun Dec 26 04:00:03 PST 2010


On Sunday 26 December 2010 02:38:53 Walter Bright wrote:
> Daniel Gibson wrote:
> > I don't think so. They're much more clean and readable than goto (they
> > just restart/jump behind the current loop or, if you use them with
> > labels, an outer loop - IMHO that's quite different from jumping to
> > arbitrary labels).
> > I guess this is the reason why break and continue are supported in Java
> > but goto isn't.
> 
> Use of break and continue guarantee two important characteristics over
> goto:
> 
> 1. initialization of a variable cannot be skipped
> 
> 2. loops can only have one entry point
> 
> The latter is called having a "reducible flow graph", which is an important
> requirement for many optimizations. (1), of course, can hide an ugly
> problem.

Essentially any conditional or loop construct translates to jump commands in 
assembly. So, in that sense, _everything_ is a goto. However, by using if 
statements and for loops and the like, that jumping around is tightly controlled 
and doesn't make code hard to read or understand. Even statements such as goto 
case 2; are highly controlled in comparison to jumps in assembly code. I do 
think that code should be written in a manner which is clear and does not have 
undue jumping around, but what we have generally leads to quite readable and 
understandable code unless is someone is incompetent or purposely trying to be 
obtuse. The original complaints put forth about goto some 30+ years ago apply to 
a _very_ different time and a _very_ different coding style than _anything_ we see 
now.

Personally, I use break and continue all the time. Does my average loop use 
them? No. But they're frequently useful really the only way to get around them 
is to use extra variables in conditions, which just makes code _harder_ to read 
and more bug-prone.

Sure, there's plenty of poorly-written code out there and it makes sense to 
complain about it when you have to deal with it, but that doesn't mean that the 
language constructs are bug-prone or poorly-designed, just that they're poorly 
used. _Any_ language construct can be abused or misused. break and continue are 
fine constructs, and the labeled break and continue in D just makes them that 
much better, and I think that that extra ability actully _reduces_ bugs, because 
it allows you to simplify the code in many multi-level loops.

- Jonathan M Davis


More information about the Digitalmars-d mailing list