Home > Archive > Fortran > September 2006 > exit and reenter a subroutine
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
exit and reenter a subroutine
|
|
| toscalives@hotmail.com 2006-09-21, 7:04 pm |
| Sorry if someone has answered this before, but I'm new here (and new to
programming).
How do you exit a subroutine, then come back in the place where you
left off, instead of at the beginning?
| |
| Rich Townsend 2006-09-21, 7:04 pm |
| toscalives@hotmail.com wrote:
> Sorry if someone has answered this before, but I'm new here (and new to
> programming).
>
> How do you exit a subroutine, then come back in the place where you
> left off, instead of at the beginning?
>
You could split the subroutine into two individual subroutines, with the break
at the comeback point. Then call them from a wrapper routine:
subroutine mysub(...)
...
logical, save :: comeback = .FALSE.
if(comeback) then
call mysub_after_comeback(...)
comeback = .FALSE.
else
call mysub_before_comeback(...)
comeback = .TRUE.
endif
end subroutine mysub
cheers,
Rich
| |
|
|
| glen herrmannsfeldt 2006-09-21, 7:04 pm |
| toscalives@hotmail.com wrote:
> Sorry if someone has answered this before, but I'm new here (and new to
> programming).
> How do you exit a subroutine, then come back in the place where you
> left off, instead of at the beginning?
A sample would help. I think the usual way is to have an argument
that indicates what you want the subroutine to do. Sometimes the
first call will initialize something and later calls will process it.
A logical or integer variable can be used to tell it what you want.
You then have to be sure your data stays around. Sometimes that means
static (as in SAVE statement), other times it is stored in a data
structure passed back from the first call and into the second call.
You might also look at ENTRY, but it probably isn't the best solution.
-- glen
| |
| Richard E Maine 2006-09-21, 7:04 pm |
| Bil Kleb <Bil.Kleb@NASA.gov> wrote:
> toscalives@hotmail.com wrote:
> This is also known as a continuation -- see
>
> http://en.wikipedia.org/wiki/Continuation
And one of the links on that page is to the Wikipedia entry for
coroutine. Coroutines were strongly pushed for f2008 by one J3 member.
(I think I recall that he had also pushed them for f2003, though I could
be confusing timelines there). He didn't have a lot of success in
selling the idea of adding them to Fortran, but it wasn't for lack of
trying.
I'll not go into all the pros and cons, though I'll add the note that I
was personally against the addition because I thought it added a mess
that would need an awful lot of work to properly integrate with the rest
of the language; I didn't see the cost/benefit as being favorable.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain| experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
| |
| toscalives@hotmail.com 2006-09-21, 7:04 pm |
|
Thanks for your replies! My reference book says that ENTRY point
statements are to be strongly discouraged and that modern Fortran
programs have no use of them. The subroutine I'm working on is part of
a big, complicated program that combines F-77 features with newer
features. So that's probably not an issue!
the program actually goes like this:
1 Main program starts
2 At some point, call subroutine
3 At some point through the subroutine, go back to main program and run
a certain part again.
4 Return to subroutine. Based on results from #3, either go on, save
the data, or change some parameters and repeat #3
This kind of thing happens several times in the subroutine. Understand
what I'm trying to say? There must be a way to do this fairly easily.
| |
| glen herrmannsfeldt 2006-09-21, 7:04 pm |
| toscalives@hotmail.com wrote:
> Thanks for your replies! My reference book says that ENTRY point
> statements are to be strongly discouraged and that modern Fortran
> programs have no use of them.
That sounds about right. They still have uses, but fairly rare.
(snip)
> the program actually goes like this:
> 1 Main program starts
> 2 At some point, call subroutine
> 3 At some point through the subroutine, go back to main program and run
> a certain part again.
> 4 Return to subroutine. Based on results from #3, either go on, save
> the data, or change some parameters and repeat #3
> This kind of thing happens several times in the subroutine. Understand
> what I'm trying to say? There must be a way to do this fairly easily.
If parts 2 and 4 don't overlap at all, they could be separate
subroutines. For problems like this, it is best if the subroutine
doesn't keep any state information between calls.
If they do overlap, such that some statements are executed in
both 2 and 4, then an IF/ENDIF block around the statements that
you don't want executed in one case and an argument to indicate
that usually works well.
-- glen
| |
| beliavsky@aol.com 2006-09-21, 7:04 pm |
|
toscalives@hotmail.com wrote:
> Thanks for your replies! My reference book says that ENTRY point
> statements are to be strongly discouraged and that modern Fortran
> programs have no use of them. The subroutine I'm working on is part of
> a big, complicated program that combines F-77 features with newer
> features. So that's probably not an issue!
>
> the program actually goes like this:
> 1 Main program starts
> 2 At some point, call subroutine
> 3 At some point through the subroutine, go back to main program and run
> a certain part again.
Ideally, the calculations in part 3 could be placed in a subroutine
that is called from the subroutine entered in step 2. Why is this not
possible?
> 4 Return to subroutine. Based on results from #3, either go on, save
> the data, or change some parameters and repeat #3
> This kind of thing happens several times in the subroutine. Understand
> what I'm trying to say? There must be a way to do this fairly easily.
| |
| toscalives@hotmail.com 2006-09-21, 7:04 pm |
| Thanks, everyone!
A simpler way of saying what I have to do is:
At different points in the subroutine, return to the same part of the
main program each time. Each time the subroutine will analyze the
result of that part of the main program.
| |
| glen herrmannsfeldt 2006-09-21, 7:04 pm |
| toscalives@hotmail.com wrote:
> At different points in the subroutine, return to the same part of the
> main program each time. Each time the subroutine will analyze the
> result of that part of the main program.
In that case, move those parts out of main and into a subroutine.
It is not so obvious what the best size for a subroutine or
main program is, but in a case like that it seems like that
code should be out of main.
-- glen
| |
| James Giles 2006-09-22, 10:00 pm |
| Richard E Maine wrote:
> Bil Kleb <Bil.Kleb@NASA.gov> wrote:
>
>
> And one of the links on that page is to the Wikipedia entry for
> coroutine [...]
That's what I thought of for the OP's original question. But he
wanted to return from his procedure and then have it take up
where it left off when called again. Using SAVED local
variables and assigned GOTOs would work (he ducks as if
the sky was about to fall because of the lack of political
correctness of the suggestion).
I think the OP should rethink his control flow so that the
whole problem won't arise.
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
| |
| Brooks Moses 2006-09-22, 10:00 pm |
| James Giles wrote:
> Richard E Maine wrote:
>
> That's what I thought of for the OP's original question. But he
> wanted to return from his procedure and then have it take up
> where it left off when called again. Using SAVED local
> variables and assigned GOTOs would work (he ducks as if
> the sky was about to fall because of the lack of political
> correctness of the suggestion).
Yup, that's what I was thinking of, too. (I've been pondering how to
implement coroutines in Fortran for a while, with the assumption that it
would be done in a preprocessor so the politically-incorrect bits :) are
hidden from the programmer.)
The tricky bit is that, in a lot of cases where one would use this, it
doesn't actually work without a fair bit of extra effort. Because, in
many cases where one is returning anywhere except at the end of the code
(in which case saved variables are sufficient), the return is inside a
block IF or DO construct, and one can't jump back there.
If one is doing this manually, and if the return is at the end of the IF
block, then one can jump back to a label after the END IF. But that's
not always the case, and even when it is, it's tricky to do in a
preprocessor.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
|
|
|
|
|