- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Shot in the dark... is there a way to have the compiler issue a warning when the name of a local variable (defined in a procedure contained in a module or submodule) collides with the name of another variable in the host module (or parent module, if the procedure is contained in a submodule)?
MODULE M IMPLICIT NONE INTEGER :: I CONTAINS SUBROUTINE S IMPLICIT NONE INTEGER :: I END SUBROUTINE S END MODULE M
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Nope - this is a standard language feature.relied on by many users.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What you can do is in SUBROUTINE S, after IMPLICIT NONE, is to comment out all the variable declarations. The variables used in S that do not have "not defined" errors have name conflicts. Note, you may also receive type, rank, size, and/or shape error messages and these will mean the name of the variable is defined, but as a different type, rank, size, and/or shape. A few iterations of comment, compile, uncomment some, compile, ... and you should have things sorted out.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Jim for the trick!
As Steve mentioned, having access to host variables is very useful (and used extensively) - but now having layers of nested submodules makes it a little more 'dangerous' (for lack of a better word) than in the past, since it is easier to forget or lose track of variables declared somewhere else than where the procedure is CONTAINed. Having a warning for this (optionally activated) would be a nice-to-have feature (I don't know if this is feasible though).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OP,
You also have ONLY to exclude those variables from the module not intended. Though in a sub-module it is not possible (to my understanding) to ONLY-fy the parent modules variables.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OP wrote:
.. having access to host variables is very useful (and used extensively) - but now having layers of nested submodules makes it a little more 'dangerous' (for lack of a better word) than in the past, since it is easier to forget or lose track of variables declared somewhere else than where the procedure is CONTAINed. Having a warning for this (optionally activated) would be a nice-to-have feature (I don't know if this is feasible though).
Fortran 2015 extends IMPORT statement to include, "IMPORT, ONLY : list", "IMPORT, NONE", and "IMPORT, ALL" and to apply it to CONTAINed subprogram and BLOCK constructs.
Just like enhanced interoperability with C from Fortran 2015, it will be highly welcome news if Intel implements this feature even before the standard revision is officially released.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Another option is to put the module "global" variables in a separate module (data only with an empty contains section). Then in your module USE this data module in the module subroutines making use of the ONLY feature for the variables actually used. This is more work but name conflicts are avoided (you will get an error) AND if you look at the top of any sub-program you can see exactly where every item comes from and what is actually used in the routine.
The only problem is that you can have USE module_name, ONLY: routine_name and not actually use routine_name as the "warn unused" doesn't cover this case within modules.....
The Fortran 2015 features FF mentions look really really useful! YES PLEASE.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This extension of the IMPORT statement in Fortran 2015 looks exactly like what I need! Thanks FF for bringing this to my attention.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page