Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28385 Discussions

How to define a dynamic array which is global (common)

hamid3252
Beginner
1,449 Views
Hi,
I have defined a dynamic array like this:
integer, dimension(:), allocatable::nCommonIndex
But still could not figure out how I can make it a global variable. I tried this syntax just after the decleration:
common /nCommon/ nCommonGrainIndex
But it gives me the error saying:
error #6406: Conflicting attributes or multiple declaration of name. [NCOMMONGRAININDEX]
common /nCommon/ nCommonGrainIndex
-----------------------^
Appreciate if you can help me with this issue.
Thanks,
HR.
0 Kudos
9 Replies
Arjen_Markus
Honored Contributor I
1,449 Views
You should be aware that Fortran does not have truly global variables. You can share
variables byCOMMON blocks (the ancient way that you should avoid) and modules.

Try:

module commons
integer, dimension(:), allocatable :: nCommonIndex
end module commons

And wherever you need this array:

subroutine needToUseCommons
use commons ! The name of the module

...
allocate( nCommonIndex(10) ) ! Allocate it for further use
...
end subroutine needToUSeCommons


Regards,

Arjen
0 Kudos
hamid3252
Beginner
1,449 Views
ThanksArjen! But what I really need is a shared memory (an array with dynamic size), similar to a singleton pattern we can define in JAVA or C++ through "static" decleration. One of my subroutines can be invoked by multiple threads and this is an array I am sharing among them. I doubt that the module-methodology you suggest (which are essencially classes in new Fortran) acts the same way, whereas a COMMON block (though deprecated) does it well. Am I missing something?
Rgds,
HR
0 Kudos
Arjen_Markus
Honored Contributor I
1,449 Views
No, a module variable is a singleton, to use "patternspeak". There can be only one copy in the
entire program. In that way it behaves as a COMMON block - but from the point of view of
robustness and maintainability, it is much more convenient than COMMON blocks as you
define it in one single place and use it anywhere via the USE statement without any chance
of not exactly using the same declarations, as can happen with COMMON blocks.

Regards,

Arjen
0 Kudos
hamid3252
Beginner
1,449 Views
Thanks! Let me modify my code and try it.
0 Kudos
hamid3252
Beginner
1,449 Views
I created a file (commonVars.f90) and defined a module like this:
[bash]module commonVarsModule
  CHARACTER::command*200
module commonVarsModule[/bash]
in another file, I have a subroutine using this module as:
[bash]subroutine testSub()
!{
  !IMPLICIT double precision (A-H,O-Z)
  use commonVarsModule
  implicit none
  
  command = ""
!}
end subroutine testSub[/bash]
It is compiled well, but I am getting linker error. Sounds like no where any reference is defined by the fortran compiler.
Umat-Main-Mgr-Test-0032.obj : error LNK2019: unresolved external symbol COMMONVARSMODULE_mp_COMMAND referenced in function TESTSUB
Do I need to define a variable of this type (module) somewhere esplicitly?
Thanks,
HR.
0 Kudos
mecej4
Honored Contributor III
1,449 Views
When you compile the file containing the module, a .MOD file and a .OBJ file are produced. At link time, you should include the .OBJ file in the command line to avoid the "unresolved external symbol" message for the module-level variables.
0 Kudos
hamid3252
Beginner
1,449 Views
Thanks. I included both F90 files after ifort command line and it compiled and linked them together.
0 Kudos
hamid3252
Beginner
1,449 Views
May I ask one more question? I would like to statically link the obj files into a single obj file as I need to finally have only a single (stand-alone) obj file. I know I can concatenate themusing "Lib" command, but then I miss the debug-information file (*.pdb) which are creadted along with the obj files in full debug mode. I am using pdb file to debug my code by attaching the runing process to VS2008 debugger. Is it any way to go around this problem?
Thanks,
HR.
0 Kudos
Steven_L_Intel1
Employee
1,449 Views
I'm pretty sure that when you build a static library project that all the PDB information gets merged into one PDB file. This would be better than a single .obj.
0 Kudos
Reply