Related articles |
---|
are there implementation reasons for not providing a break statement i noitalmost@cox.net (noitalmost) (2011-01-13) |
Re: are there implementation reasons for not providing a break stateme DrDiettrich1@aol.com (Hans-Peter Diettrich) (2011-01-14) |
Re: are there implementation reasons for not providing a break stateme fusionfile@gmail.com (August Karlstrom) (2011-01-14) |
Re: are there implementation reasons for not providing a break stateme anton@mips.complang.tuwien.ac.at (2011-01-15) |
Re: are there implementation reasons for not providing a break stateme bc@freeuk.com (BartC) (2011-01-16) |
Re: are there implementation reasons for not providing a break stateme Pidgeot18@verizon.net (Joshua Cranmer) (2011-01-16) |
Re: are there implementation reasons for not providing a break stateme richard@cogsci.ed.ac.uk (2011-01-18) |
[9 later articles] |
From: | noitalmost <noitalmost@cox.net> |
Newsgroups: | comp.compilers |
Date: | Thu, 13 Jan 2011 13:09:29 -0500 |
Organization: | Compilers Central |
Keywords: | design, question, comment |
Posted-Date: | 14 Jan 2011 01:30:26 EST |
I've noticed that Wirth has continually rejected the idea of a break
statement and I was wonder why. Is this purely philosophical, or are
there code optimization reasons? Naive code for a break is trivial to
implement.
Is it easier to optimize loops with no break? That is, is the cost of
having extra booleans to control the loop less than the cost of
messing up the basic blocks with break?
[It's a little easy to optimize single-exit loops, but my impression is
that the motivation was more like salvation through suffering. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.