| terminate a PHP script [message #172466] |
Sat, 19 February 2011 21:56  |
bob
Messages: 11
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
how do you terminate a PHP script and ensure the footer still gets
printed?
When i use a return statement, the HTML footer doesn't go out.
|
|
|
|
| Re: terminate a PHP script [message #172467 is a reply to message #172466] |
Sat, 19 February 2011 21:59  |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/19/2011 4:56 PM, bob wrote:
> how do you terminate a PHP script and ensure the footer still gets
> printed?
>
> When i use a return statement, the HTML footer doesn't go out.
You have to allow the script to complete. Any termination, i.e. via
exit() or return will terminate processing of the entire page.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172469 is a reply to message #172466] |
Sun, 20 February 2011 00:38 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
bob wrote:
> how do you terminate a PHP script and ensure the footer still gets
> printed?
>
> When i use a return statement, the HTML footer doesn't go out.
Try:
?>
</body>
</html>
<?
exit();
?>
;-)
|
|
|
|
| Re: terminate a PHP script [message #172470 is a reply to message #172469] |
Sun, 20 February 2011 01:04 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/19/2011 7:38 PM, The Natural Philosopher wrote:
> bob wrote:
>> how do you terminate a PHP script and ensure the footer still gets
>> printed?
>>
>> When i use a return statement, the HTML footer doesn't go out.
>
> Try:
>
> ?>
> </body>
> </html>
> <?
> exit();
> ?>
>
> ;-)
ROFLMAO! Typical stoopid TNP response...
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172471 is a reply to message #172470] |
Sun, 20 February 2011 02:07 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/19/2011 8:04 PM, Jerry Stuckle wrote:
> On 2/19/2011 7:38 PM, The Natural Philosopher wrote:
>> bob wrote:
>>> how do you terminate a PHP script and ensure the footer still gets
>>> printed?
>>>
>>> When i use a return statement, the HTML footer doesn't go out.
>>
>> Try:
>>
>> ?>
>> </body>
>> </html>
>> <?
>> exit();
>> ?>
>>
>> ;-)
>
> ROFLMAO! Typical stoopid TNP response...
>
Mr. Stuckle, mind your manners.
Bill B
|
|
|
|
| Re: terminate a PHP script [message #172473 is a reply to message #172466] |
Sun, 20 February 2011 09:47 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
bob wrote:
> how do you terminate a PHP script and ensure the footer still gets
> printed?
You don't (in that order).
> When i use a return statement, the HTML footer doesn't go out.
(Do not use the `return' statement outside of functions. Do not use
includes as replacement for functions.)
One possibility:
/**
* @param $bar
* @throws Exception if $general_problem occurs
*/
function foo($bar)
{
$result = false;
if ($general_problem)
{
throw new Exception('…');
}
…
return $result;
}
$x = 42;
try
{
$ok = foo($x);
if ($ok)
{
…
}
}
catch (Exception $e)
{
…
}
/* footer */
<http://php.net/exceptions>
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16
|
|
|
|
| Re: terminate a PHP script [message #172474 is a reply to message #172473] |
Sun, 20 February 2011 15:05 |
me
Messages: 192
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/20/2011 4:47 AM, Thomas 'PointedEars' Lahn wrote:
> (Do not use the `return' statement outside of functions. Do not use
> includes as replacement for functions.)
Could you unpack that a bit, in terms of overall good practices?
Thank you,
Bill B
|
|
|
|
|
|
| Re: terminate a PHP script [message #172504 is a reply to message #172499] |
Mon, 21 February 2011 13:08 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 7:53 AM, n00m wrote:
> ......
>
> goto mmm; // return;
>
> ....
>
> ........
>
>
> mmm:;
> ?>
No, you should not use goto! It causes more problems than it solves.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172530 is a reply to message #172504] |
Mon, 21 February 2011 16:51 |
n00m
Messages: 25
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
> No, you should not use goto! It causes more problems than it solves.
Why on the earth???
"goto" can produce 10000 empty lines in no time. Like this:
$cnt = 0;
mm:
++$cnt;
echo '<BR>';
if ($cnt < 10000) goto mm;
============
HTH =)
PS
I'd suggest some variations of goto. E.g.:
1) goto_but_later_on
2) goto_two_times
3) goto_and_never_come_back
4) goto_and_come_back_with_no_delay
5) goto_and_see_what_happened_out_there(report_needed=YES/NO)
|
|
|
|
| Re: terminate a PHP script [message #172534 is a reply to message #172530] |
Mon, 21 February 2011 17:06 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 21/02/11 16:51, n00m wrote:
>> No, you should not use goto! It causes more problems than it solves.
>
> Why on the earth???
> "goto" can produce 10000 empty lines in no time. Like this:
Because there is no structure to a program that uses goto. When it fails
to work properly (and it will) it can become impossible to see how it
arrived at the point that it fails at.
> $cnt = 0;
>
> mm:
> ++$cnt;
> echo '<BR>';
> if ($cnt < 10000) goto mm;
Your goto method uses 5 lines. A while loop uses 2:
$i = 10000;
while ($i--) echo "<br>\n";
and a for loop only 1:
for ($cnt = 10000; $cnt--;) echo "<br>\n";
or:
for ($cnt = 0; $cnt < 10000; $cnt++) echo "<br>\n";
Rgds
Denis McMahon
|
|
|
|
| Re: terminate a PHP script [message #172535 is a reply to message #172534] |
Mon, 21 February 2011 17:23 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 12:06 PM, Denis McMahon wrote:
> On 21/02/11 16:51, n00m wrote:
>>> No, you should not use goto! It causes more problems than it solves.
>>
>> Why on the earth???
>> "goto" can produce 10000 empty lines in no time. Like this:
>
> Because there is no structure to a program that uses goto. When it fails
> to work properly (and it will) it can become impossible to see how it
> arrived at the point that it fails at.
>
>> $cnt = 0;
>>
>> mm:
>> ++$cnt;
>> echo '<BR>';
>> if ($cnt< 10000) goto mm;
>
> Your goto method uses 5 lines. A while loop uses 2:
>
> $i = 10000;
> while ($i--) echo "<br>\n";
>
> and a for loop only 1:
>
> for ($cnt = 10000; $cnt--;) echo "<br>\n";
>
> or:
>
> for ($cnt = 0; $cnt< 10000; $cnt++) echo "<br>\n";
>
> Rgds
>
> Denis McMahon
I fully agree about gotos. There is NO need for them. What is wrong
with this pseudocode?
===========
if (passes test for failure condition) {
... all the rest of the code for success that is already there
--- except the footer
}
footer stuff.
==========
All it does is add two lines (the if test and a closing brace) and one
level of indentation, and it does what the OP wants.
Since seeing the if-then-else first appear in Fortran circa 1980, I have
never used a single goto in any language in which I have coded.
--
Shelly
|
|
|
|
| Re: terminate a PHP script [message #172539 is a reply to message #172530] |
Mon, 21 February 2011 17:37 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 11:51 AM, n00m wrote:
>> No, you should not use goto! It causes more problems than it solves.
>
> Why on the earth???
> "goto" can produce 10000 empty lines in no time. Like this:
>
>
> $cnt = 0;
>
> mm:
> ++$cnt;
> echo '<BR>';
> if ($cnt< 10000) goto mm;
>
>
> ============
> HTH =)
>
> PS
> I'd suggest some variations of goto. E.g.:
>
> 1) goto_but_later_on
> 2) goto_two_times
> 3) goto_and_never_come_back
> 4) goto_and_come_back_with_no_delay
> 5) goto_and_see_what_happened_out_there(report_needed=YES/NO)
>
>
>
>
>
>
>
>
>
goto is NEVER needed, and SELDOM a good thing to use. It completely
violates structured programming practices and causes more problems than
it solves.
Even Kernighan and Ritchie in their book "The C Programming Language"
(on which PHP was originally based) recommend against using goto.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172540 is a reply to message #172539] |
Mon, 21 February 2011 17:53 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
> On 2/21/2011 11:51 AM, n00m wrote:
>>> No, you should not use goto! It causes more problems than it solves.
>>
>> Why on the earth???
>> "goto" can produce 10000 empty lines in no time. Like this:
>>
>>
>> $cnt = 0;
>>
>> mm:
>> ++$cnt;
>> echo '<BR>';
>> if ($cnt< 10000) goto mm;
>>
>>
>> ============
>> HTH =)
>>
>> PS
>> I'd suggest some variations of goto. E.g.:
>>
>> 1) goto_but_later_on
>> 2) goto_two_times
>> 3) goto_and_never_come_back
>> 4) goto_and_come_back_with_no_delay
>> 5) goto_and_see_what_happened_out_there(report_needed=YES/NO)
Better yet, #6
6) never_in_a_million_years_use_goto
--
Shelly
|
|
|
|
|
|
| Re: terminate a PHP script [message #172543 is a reply to message #172539] |
Mon, 21 February 2011 18:04 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
> goto is NEVER needed, and SELDOM a good thing to use. It completely
> violates structured programming practices and causes more problems than
> it solves.
By and large this is true. With one exception, I haven't used one since
1978 when I stopped using FORTRAN.
The exception was when doing some Pascal under RSX-11M. There was no
"return" statement, so I had to fake one up by putting a 999: label at
the end of any procedure where I wanted an early return, and then goto
999.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: terminate a PHP script [message #172544 is a reply to message #172543] |
Mon, 21 February 2011 18:32 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 1:04 PM, Tim Streater wrote:
> In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> goto is NEVER needed, and SELDOM a good thing to use. It completely
>> violates structured programming practices and causes more problems
>> than it solves.
>
> By and large this is true. With one exception, I haven't used one since
> 1978 when I stopped using FORTRAN.
>
> The exception was when doing some Pascal under RSX-11M. There was no
> "return" statement, so I had to fake one up by putting a 999: label at
> the end of any procedure where I wanted an early return, and then goto 999.
Again, why not if-then-else?
--
Shelly
|
|
|
|
| Re: terminate a PHP script [message #172545 is a reply to message #172544] |
Mon, 21 February 2011 18:50 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <ijub3f$cqn$2(at)news(dot)eternal-september(dot)org>,
sheldonlg <sheldonlg(at)thevillages(dot)net> wrote:
> On 21/2/2011 1:04 PM, Tim Streater wrote:
>> In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> goto is NEVER needed, and SELDOM a good thing to use. It completely
>>> violates structured programming practices and causes more problems
>>> than it solves.
>>
>> By and large this is true. With one exception, I haven't used one since
>> 1978 when I stopped using FORTRAN.
>>
>> The exception was when doing some Pascal under RSX-11M. There was no
>> "return" statement, so I had to fake one up by putting a 999: label at
>> the end of any procedure where I wanted an early return, and then goto 999.
>
> Again, why not if-then-else?
You mean, as in SESE?
Because of the incredible convolution and depth of nested if/then/else
you can get to. If I have (as it might be) a function that's scanning a
string looking for and obtaining options and their values for some
command previously scanned off the string, and I detect an error, I want
to set an error code and exit right there. I don't want any subsequent
maintainer to have to intuit that, in fact, from this point on nested
15-deep in else clauses, no more code is executed for that path through
the function.
That way I rarely get more than 3-deep in if/then/else. To me, it's all
about readbility.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: terminate a PHP script [message #172546 is a reply to message #172544] |
Mon, 21 February 2011 18:54 |
n00m
Messages: 25
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
> Again, why not if-then-else?
what if it's 10 nested for() stmts?
And you need to break out of ALL for()'s from the innermost for()?
Do you like 10 if-then-else conditionals, 1 per each for()?
|
|
|
|
| Re: terminate a PHP script [message #172547 is a reply to message #172542] |
Mon, 21 February 2011 19:07 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 21 Feb 2011 10:01:14 -0800 (PST), n00m wrote:
>
> You, guys, are so funny puristical pureeest purists =)
It's a goal. If you don't have a reason to use a GOTO that you can
clearly articulate, avoid it.
If you wanna use a GOTO, go ahead. It doesn't hurt us any. But if it
bites you in the butt later, or you need a flow question answered, you
might as well expect that you'll be asked to rewrite the thing without
the GOTO before you get a reliable answer.
--
The true sysadmin does not adjust his behaviour to fit the machine. He
adjusts the machine until it behaves properly. With a hammer, if necessary.
- Brian in the Monastery
|
|
|
|
| Re: terminate a PHP script [message #172548 is a reply to message #172545] |
Mon, 21 February 2011 19:09 |
Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Mon, 21 Feb 2011 18:50:39 +0000, Tim Streater wrote:
> Because of the incredible convolution and depth of nested if/then/else
> you can get to. If I have (as it might be) a function that's scanning a
> string looking for and obtaining options and their values for some
> command previously scanned off the string, and I detect an error, I want
> to set an error code and exit right there. I don't want any subsequent
> maintainer to have to intuit that, in fact, from this point on nested
> 15-deep in else clauses, no more code is executed for that path through
> the function.
>
> That way I rarely get more than 3-deep in if/then/else. To me, it's all
> about readbility.
*grin* for me, it's all about comprehesibility. If you don't like how
deep you're nesting, maybe you need to break something out into a
function instead....
--
The true sysadmin does not adjust his behaviour to fit the machine. He
adjusts the machine until it behaves properly. With a hammer, if necessary.
- Brian in the Monastery
|
|
|
|
| Re: terminate a PHP script [message #172552 is a reply to message #172546] |
Mon, 21 February 2011 19:39 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 1:54 PM, n00m wrote:
>
>> Again, why not if-then-else?
>
> what if it's 10 nested for() stmts?
> And you need to break out of ALL for()'s from the innermost for()?
> Do you like 10 if-then-else conditionals, 1 per each for()?
Quite simple, actually.
$stop = false;
for ($i = 0; $i < 100 && ! $stop; $i++) ...
And many other ways of doing it.
As others have said - go ahead and use goto if you want to - it won't
hurt the rest of us. But then don't complain when it bites you in the
butt - which it definitely will.
And this isn't about being purists. It is about writing good,
structured code which is maintainable.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172553 is a reply to message #172548] |
Mon, 21 February 2011 19:44 |
Tim Streater
Messages: 328
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
In article <slrnim5e3u(dot)2mh(dot)hellsop(at)nibelheim(dot)ninehells(dot)com>,
"Peter H. Coffin" <hellsop(at)ninehells(dot)com> wrote:
> On Mon, 21 Feb 2011 18:50:39 +0000, Tim Streater wrote:
>> Because of the incredible convolution and depth of nested if/then/else
>> you can get to. If I have (as it might be) a function that's scanning a
>> string looking for and obtaining options and their values for some
>> command previously scanned off the string, and I detect an error, I want
>> to set an error code and exit right there. I don't want any subsequent
>> maintainer to have to intuit that, in fact, from this point on nested
>> 15-deep in else clauses, no more code is executed for that path through
>> the function.
>>
>> That way I rarely get more than 3-deep in if/then/else. To me, it's all
>> about readbility.
>
> *grin* for me, it's all about comprehesibility. If you don't like how
> deep you're nesting, maybe you need to break something out into a
> function instead....
Of course; I agree that if you're 15 levels deep you've got a design
problem. But that's my point. Early exit helps avoid that so you can
focus on the next thing.
I have seen this sort of code, btw. Functions hundreds of lines long
with more hundreds separating "if" from the corresponding "else". I
suppose the writer could follow it, but then he was IQ200.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
|
|
|
|
| Re: terminate a PHP script [message #172559 is a reply to message #172546] |
Mon, 21 February 2011 21:03 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 1:54 PM, n00m wrote:
>
>> Again, why not if-then-else?
>
> what if it's 10 nested for() stmts?
> And you need to break out of ALL for()'s from the innermost for()?
> Do you like 10 if-then-else conditionals, 1 per each for()?
&& !$exit_all
in each of the test conditions of the for loop where $exit_all is
initially FALSE outside the outermost loop.
for ($i1=0, $exit_all=FALSE; $i1 < $i1_end && !$exit_all; $i1++) {
for ($i2=0, $exit_all=FALSE; $i2 < $i2_end && !$exit_allt; $i2++) {
..... // and so on
if ($some_condition == TRUE) {
$exit_all = TRUE;
break; // or continue which does one extra check step
}
}
}
--
Shelly
|
|
|
|
| Re: terminate a PHP script [message #172560 is a reply to message #172559] |
Mon, 21 February 2011 21:06 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 4:03 PM, sheldonlg wrote:
> On 2/21/2011 1:54 PM, n00m wrote:
>>
>>> Again, why not if-then-else?
>>
>> what if it's 10 nested for() stmts?
>> And you need to break out of ALL for()'s from the innermost for()?
>> Do you like 10 if-then-else conditionals, 1 per each for()?
>
> && !$exit_all
>
> in each of the test conditions of the for loop where $exit_all is
> initially FALSE outside the outermost loop.
>
> for ($i1=0, $exit_all=FALSE; $i1 < $i1_end && !$exit_all; $i1++) {
> for ($i2=0, $exit_all=FALSE; $i2 < $i2_end && !$exit_allt; $i2++) {
> ..... // and so on
> if ($some_condition == TRUE) {
> $exit_all = TRUE;
> break; // or continue which does one extra check step
> }
> }
> }
Correction: Only the very top level one has the $exit_all=FALSE
initializer. Cut and pasted too quickly.
--
Shelly
|
|
|
|
| Re: terminate a PHP script [message #172563 is a reply to message #172560] |
Mon, 21 February 2011 21:46 |
n00m
Messages: 25
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
On Feb 21, 11:06 pm, sheldonlg <sheldo...@thevillages.net> wrote:
> On 2/21/2011 4:03 PM, sheldonlg wrote:
>
>
>
>> On 2/21/2011 1:54 PM, n00m wrote:
>
>>>> Again, why not if-then-else?
>
>>> what if it's 10 nested for() stmts?
>>> And you need to break out of ALL for()'s from the innermost for()?
>>> Do you like 10 if-then-else conditionals, 1 per each for()?
>
>> && !$exit_all
>
>> in each of the test conditions of the for loop where $exit_all is
>> initially FALSE outside the outermost loop.
>
>> for ($i1=0, $exit_all=FALSE; $i1 < $i1_end && !$exit_all; $i1++) {
>> for ($i2=0, $exit_all=FALSE; $i2 < $i2_end && !$exit_allt; $i2++) {
>> ..... // and so on
>> if ($some_condition == TRUE) {
>> $exit_all = TRUE;
>> break; // or continue which does one extra check step
>> }
>> }
>> }
>
> Correction: Only the very top level one has the $exit_all=FALSE
> initializer. Cut and pasted too quickly.
>
> --
> Shelly
Tremendously! Toungue in cheek =)
|
|
|
|
| Re: terminate a PHP script [message #172569 is a reply to message #172535] |
Tue, 22 February 2011 00:28 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
sheldonlg wrote:
> On 2/21/2011 12:06 PM, Denis McMahon wrote:
>> On 21/02/11 16:51, n00m wrote:
>>>> No, you should not use goto! It causes more problems than it solves.
>>>
>>> Why on the earth???
>>> "goto" can produce 10000 empty lines in no time. Like this:
>>
>> Because there is no structure to a program that uses goto. When it fails
>> to work properly (and it will) it can become impossible to see how it
>> arrived at the point that it fails at.
>>
>>> $cnt = 0;
>>>
>>> mm:
>>> ++$cnt;
>>> echo '<BR>';
>>> if ($cnt< 10000) goto mm;
>>
>> Your goto method uses 5 lines. A while loop uses 2:
>>
>> $i = 10000;
>> while ($i--) echo "<br>\n";
>>
>> and a for loop only 1:
>>
>> for ($cnt = 10000; $cnt--;) echo "<br>\n";
>>
>> or:
>>
>> for ($cnt = 0; $cnt< 10000; $cnt++) echo "<br>\n";
>>
>> Rgds
>>
>> Denis McMahon
>
> I fully agree about gotos. There is NO need for them. What is wrong
> with this pseudocode?
>
> ===========
> if (passes test for failure condition) {
> ... all the rest of the code for success that is already there
> --- except the footer
> }
>
> footer stuff.
> ==========
>
> All it does is add two lines (the if test and a closing brace) and one
> level of indentation, and it does what the OP wants.
>
> Since seeing the if-then-else first appear in Fortran circa 1980, I have
> never used a single goto in any language in which I have coded.
>
Well that's cos you never wrote Assembler :-)
|
|
|
|
| Re: terminate a PHP script [message #172570 is a reply to message #172569] |
Tue, 22 February 2011 00:52 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 7:28 PM, The Natural Philosopher wrote:
> sheldonlg wrote:
>> On 2/21/2011 12:06 PM, Denis McMahon wrote:
>>> On 21/02/11 16:51, n00m wrote:
>>>> > No, you should not use goto! It causes more problems than it solves.
>>>>
>>>> Why on the earth???
>>>> "goto" can produce 10000 empty lines in no time. Like this:
>>>
>>> Because there is no structure to a program that uses goto. When it fails
>>> to work properly (and it will) it can become impossible to see how it
>>> arrived at the point that it fails at.
>>>
>>>> $cnt = 0;
>>>>
>>>> mm:
>>>> ++$cnt;
>>>> echo '<BR>';
>>>> if ($cnt< 10000) goto mm;
>>>
>>> Your goto method uses 5 lines. A while loop uses 2:
>>>
>>> $i = 10000;
>>> while ($i--) echo "<br>\n";
>>>
>>> and a for loop only 1:
>>>
>>> for ($cnt = 10000; $cnt--;) echo "<br>\n";
>>>
>>> or:
>>>
>>> for ($cnt = 0; $cnt< 10000; $cnt++) echo "<br>\n";
>>>
>>> Rgds
>>>
>>> Denis McMahon
>>
>> I fully agree about gotos. There is NO need for them. What is wrong
>> with this pseudocode?
>>
>> ===========
>> if (passes test for failure condition) {
>> ... all the rest of the code for success that is already there
>> --- except the footer
>> }
>>
>> footer stuff.
>> ==========
>>
>> All it does is add two lines (the if test and a closing brace) and one
>> level of indentation, and it does what the OP wants.
>>
>> Since seeing the if-then-else first appear in Fortran circa 1980, I
>> have never used a single goto in any language in which I have coded.
>>
> Well that's cos you never wrote Assembler :-)
>
Correct! That was before even my time. :-) By the time I got into it
with Fortran IV, the compiled code looked an awful lot like Assembly
code. Machines should be labor saving devices. That was what the
compiler was for. Besides, it is much easier to debug and maintain a
language that is readable, and not like spaghetti code (gotos and jumps).
--
Shelly
|
|
|
|
| Re: terminate a PHP script [message #172571 is a reply to message #172543] |
Tue, 22 February 2011 00:58 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>
>> goto is NEVER needed, and SELDOM a good thing to use. It completely
>> violates structured programming practices and causes more problems
>> than it solves.
>
> By and large this is true. With one exception, I haven't used one since
> 1978 when I stopped using FORTRAN.
>
> The exception was when doing some Pascal under RSX-11M. There was no
> "return" statement, so I had to fake one up by putting a 999: label at
> the end of any procedure where I wanted an early return, and then goto 999.
>
Pascal is unmitigated crap. Its a teaching language, not a language that
can be used to do anything useful. It enforces structure to the point
where you have to make a worse choice (the goto) than an early return..
Try creating a union in it as well..
PERSONALLY I find that early returns or breaks make for much easier to
follow code...that strict adherence to if then else..
so
function read_group()
{
while ($post)
{
if ($poster=="stuckle")
continue; //skip irrelevancies
//now process data you are interested in...
..
..
}
}
reads much more eailyily than
function read_group()
{
while ($post)
{
if ($poster!="stuckle")
{
....
....
..
} //endif not stuckle
}
}
Because the latter, can lead to huge nesting and lots of else if else
type constructs.
It also follows the natural economy of thought that says
'if its him, don't even go there' which is the first thing you do.
THEN there may be other reasons to skip or abort. Get the exception
processing done early, simply and quickly, and then the real meat of the
processing is all in a simple block, rather than being interspersed with
exception processing.
That's the difference between academic purism and real life software
engineering: to the purist exception processing is something small that
should not sully the smooth flow of idealised control statements: To the
engineer exception processing is the biggest source of run time errors
and program bugs, and the more its all together and the easier it is to
understand and modify, the more robust the code is likely to be.
If that means saying, or the equivalent of saying
if(condition) go to errror1
...
if (condition) go to error2
and then collecting all the error handling code in one place, where it
can all be reviewed..sod the purists. I'll use goto, continue, return or
whatever the software allows, up to and including setjmp() and
longjmp()..which allowed me to write a piece of code that had functions
nested so deep that the stack groaned under the strain, and instead of
having to check return values all the way up the return chain, I simply
discarded the whole stack, and ended up in a 'master reset with error
message' part of the code..in a time period that was short enough to
keep the employer happy.
Probably the first rule of software engineering is that there is no rule
that cannot and occasionally should be broken, and no rule that is
optimal in every case.
The goal is always clear comprehensible maintainable code that performs
the function for which it was designed: You have to ask yourself, punk,
whether use of a goto or equivalent, gets you nearer to, or further
from, that goal.
Exercises in egotistical cleverness and pedantry can, and should be,
left to usenet postings.
|
|
|
|
| Re: terminate a PHP script [message #172572 is a reply to message #172570] |
Tue, 22 February 2011 01:00 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 7:52 PM, sheldonlg wrote:
> On 2/21/2011 7:28 PM, The Natural Philosopher wrote:
>> sheldonlg wrote:
>>> On 2/21/2011 12:06 PM, Denis McMahon wrote:
>>>> On 21/02/11 16:51, n00m wrote:
>>>> >> No, you should not use goto! It causes more problems than it solves.
>>>> >
>>>> > Why on the earth???
>>>> > "goto" can produce 10000 empty lines in no time. Like this:
>>>>
>>>> Because there is no structure to a program that uses goto. When it
>>>> fails
>>>> to work properly (and it will) it can become impossible to see how it
>>>> arrived at the point that it fails at.
>>>>
>>>> > $cnt = 0;
>>>> >
>>>> > mm:
>>>> > ++$cnt;
>>>> > echo '<BR>';
>>>> > if ($cnt< 10000) goto mm;
>>>>
>>>> Your goto method uses 5 lines. A while loop uses 2:
>>>>
>>>> $i = 10000;
>>>> while ($i--) echo "<br>\n";
>>>>
>>>> and a for loop only 1:
>>>>
>>>> for ($cnt = 10000; $cnt--;) echo "<br>\n";
>>>>
>>>> or:
>>>>
>>>> for ($cnt = 0; $cnt< 10000; $cnt++) echo "<br>\n";
>>>>
>>>> Rgds
>>>>
>>>> Denis McMahon
>>>
>>> I fully agree about gotos. There is NO need for them. What is wrong
>>> with this pseudocode?
>>>
>>> ===========
>>> if (passes test for failure condition) {
>>> ... all the rest of the code for success that is already there
>>> --- except the footer
>>> }
>>>
>>> footer stuff.
>>> ==========
>>>
>>> All it does is add two lines (the if test and a closing brace) and one
>>> level of indentation, and it does what the OP wants.
>>>
>>> Since seeing the if-then-else first appear in Fortran circa 1980, I
>>> have never used a single goto in any language in which I have coded.
>>>
>> Well that's cos you never wrote Assembler :-)
>>
>
> Correct! That was before even my time. :-) By the time I got into it
> with Fortran IV, the compiled code looked an awful lot like Assembly
> code. Machines should be labor saving devices. That was what the
> compiler was for. Besides, it is much easier to debug and maintain a
> language that is readable, and not like spaghetti code (gotos and jumps).
>
Assembler isn't a structured programming language - but TNP seems unable
to grasp the difference.
Sure, goto (or BRanch, JuMP or whatever, depending on the assembler
you're using) is needed in non-structured languages. But not in
structured ones.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: terminate a PHP script [message #172574 is a reply to message #172544] |
Tue, 22 February 2011 01:06 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
sheldonlg wrote:
> On 2/21/2011 1:04 PM, Tim Streater wrote:
>> In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>>
>>> goto is NEVER needed, and SELDOM a good thing to use. It completely
>>> violates structured programming practices and causes more problems
>>> than it solves.
>>
>> By and large this is true. With one exception, I haven't used one since
>> 1978 when I stopped using FORTRAN.
>>
>> The exception was when doing some Pascal under RSX-11M. There was no
>> "return" statement, so I had to fake one up by putting a 999: label at
>> the end of any procedure where I wanted an early return, and then goto
>> 999.
>
> Again, why not if-then-else?
>
Because the nesting rapidly gets out of hand, and the 'what to do if its
NOT this' gets relegated to a bracket 5 pages further on completely
disconnected from the actual logical test that causes its invocation.
i.e.
if (condition == what we want)
{
15 pages of code all nested
}
else // condition wasn't what we wanted in this instance
{
do some other crap
}
// now bugger off back to momma
is about as unreadable as it gets.
MUCH better is
if(condition==borked)
return(borked flavour one);
...15 pages of code with no nesting that takes it of the right hand side
of the screen, or paper.
reversing the condition logic to simply make the 15 pages an else clause
dosent get rid of the nesting.
When the aeroplane is on fire, you don't want to have to reverse your
way out of the cockpit drill and flight plan. You just want to hit the
eject button and abort the mission.
|
|
|
|
| Re: terminate a PHP script [message #172575 is a reply to message #172545] |
Tue, 22 February 2011 01:12 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <ijub3f$cqn$2(at)news(dot)eternal-september(dot)org>,
> sheldonlg <sheldonlg(at)thevillages(dot)net> wrote:
>
>> On 21/2/2011 1:04 PM, Tim Streater wrote:
>>> In article <iju7sd$9fc$1(at)news(dot)eternal-september(dot)org>,
>>> Jerry Stuckle <jstucklex(at)attglobal(dot)net> wrote:
>>>
>>>> goto is NEVER needed, and SELDOM a good thing to use. It completely
>>>> violates structured programming practices and causes more problems
>>>> than it solves.
>>>
>>> By and large this is true. With one exception, I haven't used one since
>>> 1978 when I stopped using FORTRAN.
>>>
>>> The exception was when doing some Pascal under RSX-11M. There was no
>>> "return" statement, so I had to fake one up by putting a 999: label at
>>> the end of any procedure where I wanted an early return, and then
>> goto 999.
>>
>> Again, why not if-then-else?
>
> You mean, as in SESE?
>
> Because of the incredible convolution and depth of nested if/then/else
> you can get to. If I have (as it might be) a function that's scanning a
> string looking for and obtaining options and their values for some
> command previously scanned off the string, and I detect an error, I want
> to set an error code and exit right there. I don't want any subsequent
> maintainer to have to intuit that, in fact, from this point on nested
> 15-deep in else clauses, no more code is executed for that path through
> the function.
>
> That way I rarely get more than 3-deep in if/then/else. To me, it's all
> about readbility.
>
+100
Its easy to recognise people who actually write code, as opposed to
those who tell other people how they ought to write it.
Its probably easier these days with editing tools that collapse things
with curly braces round them..but those tools wouldn't need to exist if
people learnt to code properly, as opposed to simply in some
academically defined 'good ' way.
When I started in C the first thing I wrote was a program that could
print onto a dot matrix in condensed characters, simply so the nesting
did not run off the right hand side of the paper: with the editors then,
a paper printout was a lot easier to follow than onscreen.
And boy did it encourage you to structure for readability, not for
adherence to academic 'standards'
|
|
|
|
| Re: terminate a PHP script [message #172576 is a reply to message #172548] |
Tue, 22 February 2011 01:15 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Peter H. Coffin wrote:
> On Mon, 21 Feb 2011 18:50:39 +0000, Tim Streater wrote:
>> Because of the incredible convolution and depth of nested if/then/else
>> you can get to. If I have (as it might be) a function that's scanning a
>> string looking for and obtaining options and their values for some
>> command previously scanned off the string, and I detect an error, I want
>> to set an error code and exit right there. I don't want any subsequent
>> maintainer to have to intuit that, in fact, from this point on nested
>> 15-deep in else clauses, no more code is executed for that path through
>> the function.
>>
>> That way I rarely get more than 3-deep in if/then/else. To me, it's all
>> about readbility.
>
> *grin* for me, it's all about comprehesibility. If you don't like how
> deep you're nesting, maybe you need to break something out into a
> function instead....
>
Yes, but how much stack do you have? Can you afford the overhead of a
call/return? How much does splitting a whole block of code to four pages
away make the comprehensibility problem worse, not better?
|
|
|
|
| Re: terminate a PHP script [message #172577 is a reply to message #172553] |
Tue, 22 February 2011 01:16 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
Tim Streater wrote:
> In article <slrnim5e3u(dot)2mh(dot)hellsop(at)nibelheim(dot)ninehells(dot)com>,
> "Peter H. Coffin" <hellsop(at)ninehells(dot)com> wrote:
>
>> On Mon, 21 Feb 2011 18:50:39 +0000, Tim Streater wrote:
>>> Because of the incredible convolution and depth of nested
>> if/then/else > you can get to. If I have (as it might be) a function
>> that's scanning a > string looking for and obtaining options and their
>> values for some > command previously scanned off the string, and I
>> detect an error, I want > to set an error code and exit right there. I
>> don't want any subsequent > maintainer to have to intuit that, in
>> fact, from this point on nested > 15-deep in else clauses, no more
>> code is executed for that path through > the function.
>>>
>>> That way I rarely get more than 3-deep in if/then/else. To me, it's
>> all > about readbility.
>>
>> *grin* for me, it's all about comprehesibility. If you don't like how
>> deep you're nesting, maybe you need to break something out into a
>> function instead....
>
> Of course; I agree that if you're 15 levels deep you've got a design
> problem. But that's my point. Early exit helps avoid that so you can
> focus on the next thing.
>
> I have seen this sort of code, btw. Functions hundreds of lines long
> with more hundreds separating "if" from the corresponding "else". I
> suppose the writer could follow it, but then he was IQ200.
>
Nope, he used a collapsing editor, or more likely, the code is years old
and everyone has put in another few lines to cope with the issues never
addressed correctly in the original design.
|
|
|
|
| Re: terminate a PHP script [message #172578 is a reply to message #172546] |
Tue, 22 February 2011 01:23 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
n00m wrote:
>> Again, why not if-then-else?
>
> what if it's 10 nested for() stmts?
> And you need to break out of ALL for()'s from the innermost for()?
> Do you like 10 if-then-else conditionals, 1 per each for()?
Not me sir!
Thats a classic case for a goto!
Now consider 15 subroutines deep, and inside 10 for loops, and the
hardware says 'er, I lost connection to the other end'
And what you need to do is basically go to jail do not pass go, and
start over with a hardware rest/init sequence, and redo the whole thing
from start. THAT's yer longjmp(). Go to jail Do not pass Go. trash the
stack and start over.
Or consider how to write a multitasking interrupt driven scheduler in a
high level language. Its awful. You need to physically switch the
stack..to point to a stack whose location is stored - gasp - in a
global variable!
Inside an asynchronous interrupt service routine.Yuk.
|
|
|
|
| Re: terminate a PHP script [message #172580 is a reply to message #172559] |
Tue, 22 February 2011 01:24 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
sheldonlg wrote:
> On 2/21/2011 1:54 PM, n00m wrote:
>>
>>> Again, why not if-then-else?
>>
>> what if it's 10 nested for() stmts?
>> And you need to break out of ALL for()'s from the innermost for()?
>> Do you like 10 if-then-else conditionals, 1 per each for()?
>
> && !$exit_all
>
> in each of the test conditions of the for loop where $exit_all is
> initially FALSE outside the outermost loop.
>
> for ($i1=0, $exit_all=FALSE; $i1 < $i1_end && !$exit_all; $i1++) {
> for ($i2=0, $exit_all=FALSE; $i2 < $i2_end && !$exit_allt; $i2++) {
> ..... // and so on
> if ($some_condition == TRUE) {
> $exit_all = TRUE;
> break; // or continue which does one extra check step
> }
> }
> }
>
>
>
I didn't understand a word of that. ;-)
AND you used a BREAK. hanging is too good...
|
|
|
|
| Re: terminate a PHP script [message #172583 is a reply to message #172577] |
Tue, 22 February 2011 01:28 |
n00m
Messages: 25
Registered: February 2011
Karma: 0
|
Junior Member |
|
|
Does not it (the FORTRAN code below) look charming?
Btw it works perfectly (some time ago I re-wrote it
into VB and into Pascal;.. crowds of mad GOTOS =)
==================================================================
SUBROUTINE JOVOFD(N,C,X,Y,U,V,Z)
INTEGER C(100,100),X(100),Y(100),U(100),V(100)
INTEGER H,Z,L0,V0,VJ,DJ,UP,LOW
INTEGER LAB(100),D(100),FREE(100),COL(100)
C
C THIS SUBROUTINE SOLVES THE FULL DENSITY LINEAR ASSIGNMENT PROBLEM
C ACCORDING TO
C
C "A Shortest Augmenting Path Algorithm for Dense and Sparse
Linear
C Assignment Problems," Computing 38, 325-340, 1987
C
C by
C
C R. Jonker and A. Volgenant, University of Amsterdam.
C
C INPUT PARAMETERS :
C N = NUMBER OF ROWS AND COLUMNS
C C = WEIGHT MATRIX
C
C OUTPUT PARAMETERS
C X = COL ASSIGNED TO ROW
C Y = ROW ASSIGNED TO COL
C U = DUAL ROW VARIABLE
C V = DUAL COLUMN VARIABLE
C Z = VALUE OF OPTIMAL SOLUTION
C
C INITIALIZATION
DO 10 I=1,N
X(I)=0
10 CONTINUE
DO 20 J0=1,N
J=N-J0+1
VJ=C(J,1)
I0=1
DO 15 I=2,N
IF (C(J,I).LT.VJ) THEN
VJ=C(J,I)
I0=I
END IF
15 CONTINUE
V(J)=VJ
COL(J)=J
IF (X(I0).EQ.0) THEN
X(I0)=J
Y(J)=I0
ELSE
X(I0)=-ABS(X(I0))
Y(J)=0
END IF
20 CONTINUE
L=0
DO 40 I=1,N
IF (X(I).EQ.0) THEN
L=L+1
FREE(L)=I
GOTO 40
END IF
IF (X(I).LT.0) THEN
X(I)=-X(I)
ELSE
J1=X(I)
MIN=1.E14
DO 31 J=1,N
IF (J.EQ.J1) GOTO 31
IF (C(J,I)-V(J).LT.MIN) MIN=C(J,I)-V(J)
31 CONTINUE
V(J1)=V(J1)-MIN
END IF
40 CONTINUE
C IMPROVE THE INITIAL SOLUTION
CNT=0
IF (L.EQ.0) GOTO 1000
41 L0=L
K=1
L=0
50 I=FREE(K)
K=K+1
V0=C(1,I)-V(1)
J0=1
VJ=1.E14
DO 42 J=2,N
H=C(J,I)-V(J)
IF (H.LT.VJ) THEN
IF (H.GE.V0) THEN
VJ=H
J1=J
ELSE
VJ=V0
V0=H
J1=J0
J0=J
END IF
END IF
42 CONTINUE
I0=Y(J0)
IF (V0.LT.VJ) THEN
V(J0)=V(J0)-VJ+V0
ELSE
IF (I0.EQ.0) GOTO 43
J0=J1
I0=Y(J1)
END IF
IF (I0.EQ.0) GOTO 43
IF (V0.LT.VJ) THEN
K=K-1
FREE(K)=I0
ELSE
L=L+1
FREE(L)=I0
END IF
43 X(I)=J0
Y(J0)=I
IF (K.LE.L0) GOTO 50
CNT=CNT+1
IF ((L.GT.0).AND.(CNT.LT.2)) GOTO 41
C AUGMENTATION PART
L0=L
DO 90 L=1,L0
I0=FREE(L)
DO 51 J=1,N
D(J)=C(J,I0)-V(J)
LAB(J)=I0
51 CONTINUE
UP=1
LOW=1
60 LAST=LOW-1
MIN=D(COL(UP))
UP=UP+1
DO 52 K=UP,N
J=COL(K)
DJ=D(J)
IF (DJ.LE.MIN) THEN
IF (DJ.LT.MIN) THEN
MIN=DJ
UP=LOW
END IF
COL(K)=COL(UP)
COL(UP)=J
UP=UP+1
END IF
52 CONTINUE
DO 53 H=LOW,UP-1
J=COL(H)
IF (Y(J).EQ.0) GOTO 70
53 CONTINUE
55 J0=COL(LOW)
LOW=LOW+1
I=Y(J0)
H=C(J0,I)-V(J0)-MIN
DO 62 K=UP,N
J=COL(K)
VJ=C(J,I)-V(J)-H
IF (VJ.LT.D(J)) THEN
D(J)=VJ
LAB(J)=I
IF (VJ.EQ.MIN) THEN
IF (Y(J).EQ.0) GOTO 70
COL(K)=COL(UP)
COL(UP)=J
UP=UP+1
END IF
END IF
62 CONTINUE
IF (LOW.EQ.UP) GOTO 60
GOTO 55
70 DO 71 K=1,LAST
J0=COL(K)
V(J0)=V(J0)+D(J0)-MIN
71 CONTINUE
80 I=LAB(J)
Y(J)=I
K=J
J=X(I)
X(I)=K
IF (I0.NE.I) GOTO 80
90 CONTINUE
Z=0
DO 100 I=1,N
U(I)=C(X(I),I)-V(X(I))
Z=Z+C(X(I),I)
100 CONTINUE
1000 END
|
|
|
|
| Re: terminate a PHP script [message #172588 is a reply to message #172570] |
Tue, 22 February 2011 01:46 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
sheldonlg wrote:
> On 2/21/2011 7:28 PM, The Natural Philosopher wrote:
>> sheldonlg wrote:
>>> On 2/21/2011 12:06 PM, Denis McMahon wrote:
>>>> On 21/02/11 16:51, n00m wrote:
>>>> >> No, you should not use goto! It causes more problems than it solves.
>>>> >
>>>> > Why on the earth???
>>>> > "goto" can produce 10000 empty lines in no time. Like this:
>>>>
>>>> Because there is no structure to a program that uses goto. When it
>>>> fails
>>>> to work properly (and it will) it can become impossible to see how it
>>>> arrived at the point that it fails at.
>>>>
>>>> > $cnt = 0;
>>>> >
>>>> > mm:
>>>> > ++$cnt;
>>>> > echo '<BR>';
>>>> > if ($cnt< 10000) goto mm;
>>>>
>>>> Your goto method uses 5 lines. A while loop uses 2:
>>>>
>>>> $i = 10000;
>>>> while ($i--) echo "<br>\n";
>>>>
>>>> and a for loop only 1:
>>>>
>>>> for ($cnt = 10000; $cnt--;) echo "<br>\n";
>>>>
>>>> or:
>>>>
>>>> for ($cnt = 0; $cnt< 10000; $cnt++) echo "<br>\n";
>>>>
>>>> Rgds
>>>>
>>>> Denis McMahon
>>>
>>> I fully agree about gotos. There is NO need for them. What is wrong
>>> with this pseudocode?
>>>
>>> ===========
>>> if (passes test for failure condition) {
>>> ... all the rest of the code for success that is already there
>>> --- except the footer
>>> }
>>>
>>> footer stuff.
>>> ==========
>>>
>>> All it does is add two lines (the if test and a closing brace) and one
>>> level of indentation, and it does what the OP wants.
>>>
>>> Since seeing the if-then-else first appear in Fortran circa 1980, I
>>> have never used a single goto in any language in which I have coded.
>>>
>> Well that's cos you never wrote Assembler :-)
>>
>
> Correct! That was before even my time. :-) By the time I got into it
> with Fortran IV, the compiled code looked an awful lot like Assembly
> code. Machines should be labor saving devices. That was what the
> compiler was for. Besides, it is much easier to debug and maintain a
> language that is readable, and not like spaghetti code (gotos and jumps).
>
The art of writing assembler, is to MAKE it readable DESPITE the language.
And, if you wanted to write hardware code in the 80's for them new
fangled Micro Processors, that mate, was all there was!
|
|
|
|
| Re: terminate a PHP script [message #172589 is a reply to message #172583] |
Tue, 22 February 2011 01:47 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
n00m wrote:
> Does not it (the FORTRAN code below) look charming?
> Btw it works perfectly (some time ago I re-wrote it
> into VB and into Pascal;.. crowds of mad GOTOS =)
> ==================================================================
>
>
> SUBROUTINE JOVOFD(N,C,X,Y,U,V,Z)
> INTEGER C(100,100),X(100),Y(100),U(100),V(100)
> INTEGER H,Z,L0,V0,VJ,DJ,UP,LOW
> INTEGER LAB(100),D(100),FREE(100),COL(100)
> C
> C THIS SUBROUTINE SOLVES THE FULL DENSITY LINEAR ASSIGNMENT PROBLEM
> C ACCORDING TO
> C
> C "A Shortest Augmenting Path Algorithm for Dense and Sparse
> Linear
> C Assignment Problems," Computing 38, 325-340, 1987
> C
> C by
> C
> C R. Jonker and A. Volgenant, University of Amsterdam.
> C
> C INPUT PARAMETERS :
> C N = NUMBER OF ROWS AND COLUMNS
> C C = WEIGHT MATRIX
> C
> C OUTPUT PARAMETERS
> C X = COL ASSIGNED TO ROW
> C Y = ROW ASSIGNED TO COL
> C U = DUAL ROW VARIABLE
> C V = DUAL COLUMN VARIABLE
> C Z = VALUE OF OPTIMAL SOLUTION
> C
> C INITIALIZATION
> DO 10 I=1,N
> X(I)=0
> 10 CONTINUE
> DO 20 J0=1,N
> J=N-J0+1
> VJ=C(J,1)
> I0=1
> DO 15 I=2,N
> IF (C(J,I).LT.VJ) THEN
> VJ=C(J,I)
> I0=I
> END IF
> 15 CONTINUE
> V(J)=VJ
> COL(J)=J
> IF (X(I0).EQ.0) THEN
> X(I0)=J
> Y(J)=I0
> ELSE
> X(I0)=-ABS(X(I0))
> Y(J)=0
> END IF
> 20 CONTINUE
> L=0
> DO 40 I=1,N
> IF (X(I).EQ.0) THEN
> L=L+1
> FREE(L)=I
> GOTO 40
> END IF
> IF (X(I).LT.0) THEN
> X(I)=-X(I)
> ELSE
> J1=X(I)
> MIN=1.E14
> DO 31 J=1,N
> IF (J.EQ.J1) GOTO 31
> IF (C(J,I)-V(J).LT.MIN) MIN=C(J,I)-V(J)
> 31 CONTINUE
> V(J1)=V(J1)-MIN
> END IF
> 40 CONTINUE
> C IMPROVE THE INITIAL SOLUTION
> CNT=0
> IF (L.EQ.0) GOTO 1000
> 41 L0=L
> K=1
> L=0
> 50 I=FREE(K)
> K=K+1
> V0=C(1,I)-V(1)
> J0=1
> VJ=1.E14
> DO 42 J=2,N
> H=C(J,I)-V(J)
> IF (H.LT.VJ) THEN
> IF (H.GE.V0) THEN
> VJ=H
> J1=J
> ELSE
> VJ=V0
> V0=H
> J1=J0
> J0=J
> END IF
> END IF
> 42 CONTINUE
> I0=Y(J0)
> IF (V0.LT.VJ) THEN
> V(J0)=V(J0)-VJ+V0
> ELSE
> IF (I0.EQ.0) GOTO 43
> J0=J1
> I0=Y(J1)
> END IF
> IF (I0.EQ.0) GOTO 43
> IF (V0.LT.VJ) THEN
> K=K-1
> FREE(K)=I0
> ELSE
> L=L+1
> FREE(L)=I0
> END IF
> 43 X(I)=J0
> Y(J0)=I
> IF (K.LE.L0) GOTO 50
> CNT=CNT+1
> IF ((L.GT.0).AND.(CNT.LT.2)) GOTO 41
> C AUGMENTATION PART
> L0=L
> DO 90 L=1,L0
> I0=FREE(L)
> DO 51 J=1,N
> D(J)=C(J,I0)-V(J)
> LAB(J)=I0
> 51 CONTINUE
> UP=1
> LOW=1
> 60 LAST=LOW-1
> MIN=D(COL(UP))
> UP=UP+1
> DO 52 K=UP,N
> J=COL(K)
> DJ=D(J)
> IF (DJ.LE.MIN) THEN
> IF (DJ.LT.MIN) THEN
> MIN=DJ
> UP=LOW
> END IF
> COL(K)=COL(UP)
> COL(UP)=J
> UP=UP+1
> END IF
> 52 CONTINUE
> DO 53 H=LOW,UP-1
> J=COL(H)
> IF (Y(J).EQ.0) GOTO 70
> 53 CONTINUE
> 55 J0=COL(LOW)
> LOW=LOW+1
> I=Y(J0)
> H=C(J0,I)-V(J0)-MIN
> DO 62 K=UP,N
> J=COL(K)
> VJ=C(J,I)-V(J)-H
> IF (VJ.LT.D(J)) THEN
> D(J)=VJ
> LAB(J)=I
> IF (VJ.EQ.MIN) THEN
> IF (Y(J).EQ.0) GOTO 70
> COL(K)=COL(UP)
> COL(UP)=J
> UP=UP+1
> END IF
> END IF
> 62 CONTINUE
> IF (LOW.EQ.UP) GOTO 60
> GOTO 55
> 70 DO 71 K=1,LAST
> J0=COL(K)
> V(J0)=V(J0)+D(J0)-MIN
> 71 CONTINUE
> 80 I=LAB(J)
> Y(J)=I
> K=J
> J=X(I)
> X(I)=K
> IF (I0.NE.I) GOTO 80
> 90 CONTINUE
> Z=0
> DO 100 I=1,N
> U(I)=C(X(I),I)-V(X(I))
> Z=Z+C(X(I),I)
> 100 CONTINUE
> 1000 END
>
>
were comments not a feature of FORTRAN?
|
|
|
|
| Re: terminate a PHP script [message #172590 is a reply to message #172576] |
Tue, 22 February 2011 01:53 |
sheldonlg
Messages: 166
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 2/21/2011 8:15 PM, The Natural Philosopher wrote:
> Peter H. Coffin wrote:
>> On Mon, 21 Feb 2011 18:50:39 +0000, Tim Streater wrote:
>>> Because of the incredible convolution and depth of nested
>>> if/then/else you can get to. If I have (as it might be) a function
>>> that's scanning a string looking for and obtaining options and their
>>> values for some command previously scanned off the string, and I
>>> detect an error, I want to set an error code and exit right there. I
>>> don't want any subsequent maintainer to have to intuit that, in fact,
>>> from this point on nested 15-deep in else clauses, no more code is
>>> executed for that path through the function.
>>>
>>> That way I rarely get more than 3-deep in if/then/else. To me, it's
>>> all about readbility.
>>
>> *grin* for me, it's all about comprehesibility. If you don't like how
>> deep you're nesting, maybe you need to break something out into a
>> function instead....
>>
> Yes, but how much stack do you have? Can you afford the overhead of a
> call/return? How much does splitting a whole block of code to four pages
> away make the comprehensibility problem worse, not better?
If you have fifteen pages of code within a success bracket, then you are
at least 8-10 times too big in the routine. It should be broken into
smaller segments. I know that that when I have a piece of code that is
getting lengthy, I either put some of it in functions, or I make a more
liberal use of include files and put blocks of code in include files.
It makes it MUCH more readable and maintainable that way.
-
Shelly
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]