Replacement for COMMON

[waynebruce]

I am tired of having to pass variables back and forth across subroutines. I also do not wish to use COMMON statements in the old Fortran. Is there a way to do so in CVF? I am not too familier with POINTERS, so not sure how that would work. Maybe some info that'll get me started? I am trying to work my way through the POINTERs section in the help file, but it's not exactly a tutorial, and is kind of cryptic in its explanation.

[james1]

First, you should never get "tired" when programming, it leads to shortcuts which ultimately will produce further problems down the road.

What you likely want is not pointers, but derived types. This will allow you to define numerous "variables" that are referenced in masse by the name of the derived type.

So instead of having to do:

call sub (a, b, c, d, e, f)
call sub2 (a, c, d, e, g)

You would instead have something like:

call sub (t)
call sub2 (t)

Of course you will have to reference each of the original variables as t%a, t%b, t%c, etc.

James

[Steven_L_Intel1]

I would suggest the standard Fortran feature of modules, rather than derived types. Variables declared in modules are a great replacement for COMMON.

An example:

module mymod
integer a,b,c,d
end module mymod

subroutine sub1
use mymod
... a,b,c,d now available
end subroutine mymod

See the Language Reference Manual, or a good Fortran 9x tutorial, for more on modules.

Steve

[waynebruce]

Modules seem good. lemme try that. thanks for the suggestions.

[waynebruce]

Question: Can I have multiple different modules? As in:

module one
integer a, b, c, d
end module one

module two
integer e, f, g, h
end module two

subroutine check
use two
use one
end subroutine check

Is that possible? thanks.

[james1]

Yes, and that is a good way to reduce potential naming collisions with the global variables you are defining in the various modules.

James

[waynebruce]

What does it mean "A specification statement cannot appear in the executable section."? Does it mean I can't have modules in the PROGRAM file, but instead have to have it in a SUBROUTINE file?

[james1]

You probably placed your USE statement after an executable statement in the body of your program. Try placing any USE statements immediately following the PROGRAM line.

James

[waynebruce]

I'm sorry, still having trouble with this. I currently have something like this:

PROGRAM MAIN

MODULE ONE
...module declarations
END MODULE ONE

...begin main program declarations
...main program
END

That didn't work at all. The only way I can get the error message to go away is like this:

PROGRAM MAIN
...main program
END

MODULE ONE
...module declarations
END MODULE ONE

Now that's fine 'n all, but wouldn't that imply the module existed outside the main program? How would the main program, let along the subroutines, know that the MODULE is sitting there, since the main program doesn't even get there until after it ended?

[james1]

Programs and modules are program units and are defined separately (i.e. not nested). Typically modules are defined in separate files, and when you compile them you get .MOD files which are what the USE statements look for.

If you have everything in one source file, you simply need to have the MODULE defined prior to any USE statement that refers to it in a subsequent program unit.

James

[waynebruce]

I see. So if I have a separate file containing all my MODULE declarations, and compled to get a .MOD file, the subroutines that contain the USE statements would automatically know where to look, even if the main program doesn't actually call the MODULEs explicitly?

[waynebruce]

One last question. Can I modify the values of the variables defined in the Modules? For example, if I declared INTEGER a, b, c in a module, then I made changes to all the integers through various operations, are the values now carried across? Would another subroutine see the new values if it used the same module again?

thanks,

Wayne

[Steven_L_Intel1]

Yes. Typically, each MODULE goes in its own source file. If you are using Developer Studio, it will automatically build everything in the right order. Also, one module can USE another module, which sometimes makes sense. Group related declarations in a single module.

Modules can contain variables, PARAMETER constants, derived types and routines.

Steve