|
|
 Up |
|
|
  |
Author: ShawnShawn Date: Feb 26, 2008 12:45
I encountered this (edited for readability) and when I tried to dump
the goto and change it to an If Then I got a "label 170 missing" error
pointing me to the call statement. Included the sub's header in case
it is useful to someone.
If (condition) Goto 170
...
Call EWER(*170)
...
170 ...
Subroutine EWER(*)
Can someone tell me what is going on here?
|
| |
|
| | 30 Comments |
|
|
Author: Michael MetcalfMichael Metcalf Date: Feb 26, 2008 12:54
>I encountered this (edited for readability) and when I tried to dump
> the goto and change it to an If Then I got a "label 170 missing" error
> pointing me to the call statement. Included the sub's header in case
> it is useful to someone.
>
> If (condition) Goto 170
> ...
> Call EWER(*170)
> ...
> 170 ...
>
>
> Subroutine EWER(*)
>
> Can someone tell me what is going on here?
|
| Show full article (0.85Kb) |
|
| | no comments |
|
|
Author: ShawnShawn Date: Feb 26, 2008 13:04
> It is an alternate return ("Fortran 95/2003 Explained" App. B.1.9), an
> obsolescent feature. You will find that EWER contains a statement 'return 1'
> which, when executed, will transfer control to that statement whose label
> first appears in the actual arguments preceded by an *, to wit 170.
Indeed there is a "return 1" in the sub. Can this be obsolete
reference be eliminated by changing the offending subroutine into a
function that returns either a 1 or 0 and having a conditional handle
that value returned?
|
| |
| 3 Comments |
|
|
Author: Dick HendricksonDick Hendrickson Date: Feb 26, 2008 13:11
Shawn wrote:
>> It is an alternate return ("Fortran 95/2003 Explained" App. B.1.9), an
>> obsolescent feature. You will find that EWER contains a statement 'return 1'
>> which, when executed, will transfer control to that statement whose label
>> first appears in the actual arguments preceded by an *, to wit 170.
>
> Indeed there is a "return 1" in the sub. Can this be obsolete
> reference be eliminated by changing the offending subroutine into a
> function that returns either a 1 or 0 and having a conditional handle
> that value returned?
Yes, but it's not usually a good idea to convert subroutines into
function unless you are sure about how they work and how they
will be used (IMO). A better approach is to replace the *
arguments by a variable and test it's value after the call.
...
|
| Show full article (0.99Kb) |
| no comments |
|
|
Author: ShawnShawn Date: Feb 26, 2008 13:30
Thanks for the help guys.
Shawn
|
| |
| no comments |
|
|
Author: James GilesJames Giles Date: Feb 28, 2008 20:19
Dick Hendrickson wrote:
> [...] A better approach is to replace the *
> arguments by a variable and test it's value after the call.
> call ewer (switch)
> if (switch .eq. 1) go to 170
>
> It's a little general and allows for more return values and for
> subroutines that have more than one alternate return.
On the other hand, once you're familiar with the alternate
return feature, it's easier to read (and can often work faster
depending on the compiler). If you have lots of code that
needs to be fault tolerant, the "obsolescent" alternate
return feature is the only kind of exception handling
feature Fortran has.
--
J. Giles
|
| Show full article (0.91Kb) |
| 2 Comments |
|
|
Author: Sebastian HanigkSebastian Hanigk Date: Feb 29, 2008 00:30
"James Giles" worldnet.att.net> writes:
> On the other hand, once you're familiar with the alternate
> return feature, it's easier to read (and can often work faster
> depending on the compiler). If you have lots of code that
> needs to be fault tolerant, the "obsolescent" alternate
> return feature is the only kind of exception handling
> feature Fortran has.
I would advise against the alternate return facility from a software
engineering point of view because it is in violation of the "single
entry - single exit" directive. The simulation code I'm working with at
the moment has routines with three, four, even five alternate returns
which is a complete nightmare to read or extend (yes, the calling
routines are sprinkled with labels and GOTOs, there is no consistency in
label numbers, headaches galore).
If you use the alternate return with only one alternative in a
consistent manner, e.g. as a means to jump to a (consistently numbered)
label for error handling, cleanup and the like, I don't think it's a bad
idea as such - but a returned error code is in my opinion preferable.
Sebastian
|
| |
| no comments |
|
|
Author: Arjen MarkusArjen Markus Date: Feb 29, 2008 00:38
On 29 feb, 09:30, Sebastian Hanigk wrote:
> "James Giles" worldnet.att.net> writes:>> On the other hand, once you're familiar with the alternate
>> return feature, it's easier to read (and can often work faster
>> depending on the compiler). If you have lots of code that
>> needs to be fault tolerant, the "obsolescent" alternate
>> return feature is the only kind of exception handling
>> feature Fortran has.
>
> I would advise against the alternate return facility from a software
> engineering point of view because it is in violation of the "single
> entry - single exit" directive. The simulation code I'm working with at
> the moment has routines with three, four, even five alternate returns
> which is a complete nightmare to read or extend (yes, the calling
> routines are sprinkled with labels and GOTOs, there is no consistency in
> label numbers, headaches galore).
>
> If you use the alternate return with only one alternative in a
> consistent manner, e.g. as a means to jump to a (consistently numbered)
> label for error handling, cleanup and the like, I don't think it's a bad ...
|
| Show full article (1.95Kb) |
| no comments |
|
|
Author: SimonGSimonG Date: Feb 29, 2008 05:01
On Feb 29, 8:38 am, Arjen Markus wrote:> On 29 feb, 09:30, Sebastian Hanigk wrote:
>
>
>
>> "James Giles" worldnet.att.net> writes:>>> On the other hand, once you're familiar with the alternate
>>> return feature, it's easier to read (and can often work faster
>>> depending on the compiler). If you have lots of code that
>>> needs to be fault tolerant, the "obsolescent" alternate
>>> return feature is the only kind of exception handling
>>> feature Fortran has.
>
>> I would advise against the alternate return facility from a software
>> engineering point of view because it is in violation of the "single
>> entry - single exit" directive. The simulation code I'm working with at
>> the moment has routines with three, four, even five alternate returns
>> which is a complete nightmare to read or extend (yes, the calling
>> routines are sprinkled with labels and GOTOs, there is no consistency in
>> label numbers, headaches galore). ...
|
| Show full article (2.38Kb) |
| no comments |
|
|
|
|
|
Author: Sebastian HanigkSebastian Hanigk Date: Feb 29, 2008 06:35
> One thing that is attractive about alternate returns as
> a means to capture exceptional circumstances (IMHO) is that
> the user _has_ to decide what to do with them:
>
> call some_routine( ..., error_code )
> if ( error_code /= 0 ) then
> ... handle the error ...
> endif
>
> could easily become:
>
> call some_routine( ..., dummy )
A major parallelisation library whose name shall not be given :-) forces
exactly this kind of code because the return value is in all but a few
pathological cases irrelevant.
Usually I'm employing a simple wrapping module which gives me a
F90/95/2003 interface with OPTIONAL dummy arguments for those libraries.
|
| Show full article (1.13Kb) |
| no comments |
|
RELATED THREADS |
|
|
|
|
|
|
