Silverfrost Forums

Welcome to our forums

Using Several Moduls

9 Nov 2012 7:23 #10999

Compared to COMMON areas MODULS have very big advantages: They can be included in DLLs and they can hold dynamic allocatable arrays. Our new developments use only MODULS but no COMMON at all. We have a collection of global MODULS and several local MODULS for application programs.

When e.g. a global MODUL contains a variable iPosXYZ and a local MODULE includes a variable with the same name iPosXYZ and both moduls are used inside the same function we get no warning or error message but unexpected results. This is contrary to the use of COMMON areas from INCLUDE files.

Enhancement of the compiler will be appreciated.

Erwin

9 Nov 2012 9:20 #11002

Thank you. I already have this as an issue to look at.

9 Nov 2012 11:56 #11009

I'm puzzled. What do you expect the compiler should do in response to having the same variable name used in 2 modules?

10 Nov 2012 9:46 #11013

Quoted from JohnCampbell I'm puzzled. What do you expect the compiler should do in response to having the same variable name used in 2 modules?

If the same name really does appear in two USED modules, then the code is not standard conforming and the compiler should issue an error.

But, I'm not clear what the OP means by 'local module' and 'global module' here. If he/she means (1) one module variable, and (2) one local variable or host associated variable of the same name, then variable (2) should take precedent over and 'hide' variable (1). AFAIK this works properly in the compiler.

11 Nov 2012 12:44 #11018

I have seen examples of duplicate variables, I think a variable name being both local and in a module. I am not sure if this can be legally done, but it certainly is confusing code that I would not recommend. My best adviced is don't do it. Fix it. There must be a way of changing the code to avoid this, even if it takes a bit of effort and checking with global editing.

John

11 Nov 2012 5:02 #11019

Having a local variable with the same name as one in a USED module is OK. The local variable can be accessed and the global one can't. It isn't good practise though.

I find the best practise is to always use ONLY with USE statements:

If I want to use a local variable with the same name as one in a module, I don't include it in the ONLY list.

If I want to use a variable in a module that has the same name as one of my local variables, I usually rename one of them in the editor, or occasionally (when the module is supplied in a library and I don't have the source code), I use the rename facility with USE and prepend the module name, e.g.

SUBROUTINE AAA
    USE mymod, ONLY: mymod_var => var, a, b
    REAL :: var
   ! var and mymod_var now both accessible and easy to distinguish
END SUBROUTINE AAA

The same rules and techniques apply to subroutines and functions too.

16 Mar 2013 2:40 #11792

Erwin

Now I have come to look at this, I can not find a sample program to illustrate the problem.

Can you supply some sample code so that I know exactly what is happening.

16 Mar 2013 9:05 #11794

Quoted from EKruck This is contrary to the use of COMMON areas from INCLUDE files. Erwin

Erwin, If in local subroutine you gave the name to the variable which coincides with the same name and type variable in COMMON while is doing completely different things your are screwed. Compiler can not determine this wrong.

In MODULE case, i agree, if local and global names of variable by mistake coincide, compiler not only must issue big fat error message, it should shut down the whole computer if you keep not reacting. LOL

Please login to reply.