- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, black belts,
If the functions and subroutines in the module are so many and so big, I want to disperse the module into
different files, is it possible ? if yes, How to implement?
by the way, what integrated editor enviroment can display the function and subroutine in module in the list
form like VS displays class member?
Link Copied
6 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the functions and subroutines are in a module, you cannot separate them at this time. The Fortran 2008 "submodules" feature would allow you to do this, but Intel Fortran does not yet support this.
There is no tool in the editor that will list the functions and subroutines. The next major release, due soon, will have an option to generate a listing file with cross reference, so you could look at that to find procedures.
There is no tool in the editor that will list the functions and subroutines. The next major release, due soon, will have an option to generate a listing file with cross reference, so you could look at that to find procedures.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You could experiment withmoving the functions and subroutines to seperate files, named with a prefix name of the module name followed by the subroutine name as used within the module. Replace the subroutines and functions with interfaces to the now aliased entry point name using
cDEC$ ATTRIBUTES ALIAS: external-name:: subprogram
to rename the module familial name to the external module prefixed name.
module foo
...
contains
... ! data here
subroutine bar()
...
---------- becomes ------------
module foo
...
contains
... ! data here
! was subroutine bar()
!DEC$ ATTRIBUES ALIAS: foo_bar:: bar
interface
subroutine bar()
end subroutine bar
end interface
...
Then create a library project named foo_lib
holding the foo_bar, foo_tweedledee, ...
Jim Dempsey
cDEC$ ATTRIBUTES ALIAS: external-name:: subprogram
to rename the module familial name to the external module prefixed name.
module foo
...
contains
... ! data here
subroutine bar()
...
---------- becomes ------------
module foo
...
contains
... ! data here
! was subroutine bar()
!DEC$ ATTRIBUES ALIAS: foo_bar:: bar
interface
subroutine bar()
end subroutine bar
end interface
...
Then create a library project named foo_lib
holding the foo_bar, foo_tweedledee, ...
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am not a black belt :), but I do have a few suggestions:
- The simplest is to use the INCLUDE statement (or what is the proper term?) to split the
source file into smaller ones.The module could then look like:
module mymodule
... derivedtypes and whatever
contains
include "source1.f90"
include "source2.f90"
...
endmodule
- Another solution is to split the module into smaller modules. Common derived types
can be put into a module of their own. To create a single overall module that contains
everything andcan be used as the original one:
module mymodule
use mydatamodule
use mysubmodule1
use mysubmodule2
...
end module
The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.
Regards,
Arjen
- The simplest is to use the INCLUDE statement (or what is the proper term?) to split the
source file into smaller ones.The module could then look like:
module mymodule
... derivedtypes and whatever
contains
include "source1.f90"
include "source2.f90"
...
endmodule
- Another solution is to split the module into smaller modules. Common derived types
can be put into a module of their own. To create a single overall module that contains
everything andcan be used as the original one:
module mymodule
use mydatamodule
use mysubmodule1
use mysubmodule2
...
end module
The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.
Regards,
Arjen
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting arjenmarkus
The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.
The advantage of the second method is that each source file contains a proper module and
therefore contains eveything you need to know.
...and the additional disadvantage of the first method is that it's likely to confuse the debugger and/or dependency analysis.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Arjen,
I do not believe the original problem was a request to reduce the size of an editable file. Your suggestion resolves this issue.
If the requirement were to reduce the compile time, considering IPO and potentially 1000's of functions/subroutines, then separation into a library, defined and accessible via a module will resolve this issue.
The original poster will have to determine which route is best for them.
Jim Dempsey
I do not believe the original problem was a request to reduce the size of an editable file. Your suggestion resolves this issue.
If the requirement were to reduce the compile time, considering IPO and potentially 1000's of functions/subroutines, then separation into a library, defined and accessible via a module will resolve this issue.
The original poster will have to determine which route is best for them.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the file indeed contains so many subprograms, then it is bound to be a piling up of all manner of things.
Putting related functions and subroutines in different files, grouping the code should make it all more manageable.
If all these subprograms are interconnected in asuch a way they can not be disentangled, then the OP
is in serious trouble, I'd say.
Regards,
Arjen
Putting related functions and subroutines in different files, grouping the code should make it all more manageable.
If all these subprograms are interconnected in asuch a way they can not be disentangled, then the OP
is in serious trouble, I'd say.
Regards,
Arjen
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page