×
INTELLIGENT WORK FORUMS
FOR ENGINEERING PROFESSIONALS

Log In

Come Join Us!

Are you an
Engineering professional?
Join Eng-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Eng-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Trying to get a simple function to work

Trying to get a simple function to work

Trying to get a simple function to work

(OP)
Here, the "main" program is function WinMain(), and it calls a simple function that "lives" in another *.f90 file (compiled w/ the project.  That function is this:

integer*4 function fRun(Nint)
  implicit none
  integer :: Nint
  fRun = Nint + 10
end

An Interface is presented in the declaration area of the calling program:
interface
  function fRun(Hint)
    integer Hint
  end function
end interface

integer*4 :: iResult, Hint

Later, the function is called as follows:

Hint = 2
iResult = fRun(Hint)

The system compiles & links fine.  On execution, Hint is set to 2, control goes to the function (in the other f90 file) and Nint takes on the value of 2.  fRun becomes 12, as it should.

When control returns to the calling program, Hint still knows what it should be (2) but fRun has lost its mind.  Instead of holding a value of 12, its a long, meaningless string (-2147348), which, oddly enough, is minus the value of WinMain (in case that's a clue).

BTW, I tried moving fRun to the bottom of the calling program and I got the same result.

Any ideas as to what I'm missing here?

{No, this is NOT a homework assignment; it's a rudiment of what will become a huge Fortran app.)

RE: Trying to get a simple function to work

(OP)
The answer came to me in my sleep, and I'll post it here:

The clue was, indeed, my comment:

When control returns to the calling program, Hint still knows what it should be (2) but fRun has lost its mind.  Instead of holding a value of 12, its a long, meaningless string (-2147348), which, oddly enough, is minus the value of WinMain (in case that's a clue).

There seemed to be possible conflict in functional values.  I wondered if, for some crazy reason, Fortran functions cannot call other Fortran functions!  I recreated fRun as a subroutine and tested it:  it called and performed perfectly - even living in a separate F90 file.

It surprises me that a huge deal of this show-stopping constraint isn't emphasized (or even mentioned) - in Fortran programming  documentation/guidance when one looks up "functions".  My own Fortran refs. are silent on this issue, and - unfortunately - if I ever learned this when I studied F77 way back when, I forgot it.

Oh well, live & learn ...

RE: Trying to get a simple function to work

I don't know enough about Fortran to really comment, but your interface definition does not appear to be consistent with your function description.  In your function description, you specify a return type for your function Integer*4.  Nowhere in your interface definition is there a corresponding specification, although you do specify the input variable.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

RE: Trying to get a simple function to work

(OP)
Thanks for your reply, IRstuff.  I had thought the answer was as I posted above:  a Fortran function cannot call another Fortran function.

Your point about the apparent disparity in type specification between my Interface block and fRun itself got me thinking.  I could swear that I tried to specify fRun as an integer, either via:

interface
  integer function fRun(Hint)
    integer Hint
  end function
end interface


or as

interface
  function fRun(Hint)
    integer Hint, fRun
  end function
end interface


and the the compilation choked (didn't like the reduncancy).  (btw, I'm using Compaq Visual Fortran 6.6C.)  So I omitted the spec in the Interface block.

Guess what?  I went back into my project and - just for the hell or it - rewrote the Interface block (I tried either way above) and it worked fine !!!  The project compiles/builds fine and  fRun returns the expected integer to the calling program (f.WinMain).  Sweet!

So, I guess I was right in the first place:

A Fortran function can, indeed, call another Fortran function!

Who knew?

RE: Trying to get a simple function to work

Recursive function calling is usually a mandatory part of a programming language.  Trying to write recursive algorithms without that feature is all but impossible.  The only limitation is usually the depth of the call stack.

TTFN

FAQ731-376: Eng-Tips.com Forum Policies

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Eng-Tips Forums free from inappropriate posts.
The Eng-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Eng-Tips forums is a member-only feature.

Click Here to join Eng-Tips and talk with other members! Already a Member? Login


Resources

White Paper - How ESI is Helping Move New Medical Device Product to Market Quicker & More Cost Effic
Early Supplier Involvement has long been a strategy employed by manufacturers to produce innovative products. Now, it almost seems like a necessity. Because decisions made in the design phase can positively affect product quality and costs, this can help add value to OEM bottom lines. This white paper will discuss many facets of ESI, including why it’s so valuable today, what challenges limit the benefits of ESI, how cost is impacted, and more. Download Now
White Paper - Moving to a Driverless Future
This white paper describes what we see as the best practices to support a sustainable engineering process for autonomous vehicle design. It exposes how to use simulation and testing in common frameworks to enable design exploration, verification and validation for the development of autonomous cars at a system, software and full-vehicle level to drive a mature product development process for automated driving. Download Now
Research Report - How Engineers are Using Remote Access
Remote access enables engineers to work from anywhere provided they have an internet connection. We surveyed our audience of engineers, designers and product managers to learn how they use remote access within their organizations. We wanted to know which industries have adopted remote access, which software they are using, and what features matter most. Download Now

Close Box

Join Eng-Tips® Today!

Join your peers on the Internet's largest technical engineering professional community.
It's easy to join and it's free.

Here's Why Members Love Eng-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close