- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have discovered the following behaviour which can be reproduced with the code attached to this thread.
I have lots of big old programs which uses large amount of static data (and since its windows i am limited to 2GB, even in 64 bits compilation).
I want to do minimal changes to use allocatable arrays.
I have created the following code and i am very suprised that it works:
[fxfortran] PROGRAM Dynamic_module_example IMPLICIT NONE CALL DYNAMIC_ALLOCATION CALL SUBROUTINE1 CALL SUBROUTINE2 PAUSE END PROGRAM Dynamic_module_example[/fxfortran]
[fxfortran] MODULE arrays REAL, ALLOCATABLE :: A(:),B(:),C(:) END MODULE[/fxfortran]
[fxfortran] SUBROUTINE DYNAMIC_ALLOCATION() USE arrays INTEGER*4 I ALLOCATE (A(1000000),B(1000000),C(1000000)) RETURN END SUBROUTINE[/fxfortran]
[fxfortran] SUBROUTINE SUBROUTINE1() USE arrays INTEGER*4 I DO I=1,10000 A(I)=SIN(I*1.0) B(I)=COS(I*1.0) C(I)=TAN(I*1.0) END DO RETURN END SUBROUTINE[/fxfortran]
[bash] SUBROUTINE SUBROUTINE2() CALL SUBROUTINE3 RETURN END SUBROUTINE[/bash]<
[bash] SUBROUTINE SUBROUTINE3() USE arrays INTEGER*4 I DO I=1,100 PRINT '(3F12.5)',A(I),B(I),C(I) END DO RETURN END SUBROUTINE[/bash]
Please note that i have read the documentation and haven't found a clear explanation about it.
In fact, i use the MODULE as a COMMON for dynamic variables and i wonder why my variables are correctly maintained in memory.
Is this dangerous, is this a normal behaviour ?Thank you.F.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your reply.
i didn't use the "SAVE" attribute, i just used the default compiler option (which does not USE SAVE if my memory serves me right)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Theoretically true, but only of academic interest. For all intents and purposes, module variables on modern compilers never go out of scope. Thus, SAVE attribute is required only for standard-compliance (you will get a warning if you turn on standard checking), but not really necessary.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Theoretically true, but only of academic interest. For all intents and purposes, module variables on modern compilers never go out of scope. Thus, SAVE attribute is required only for standard-compliance (you will get a warning if you turn on standard checking), but not really necessary.
Thank you for your response.
To be clear, what conclusion can i understand? Is my testcase a dangerous way to use module variables?
Thank you,
F-Xavier
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In practice - no
It is theoretically possible that therecould be a compiler/processer/OS combination that will cause this sort of code to fail because themodule hasgone out of scope. But the de facto situation at the moment is that this will "just work"
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you Steve,
It would be very nice to be clearly explained in MODULE documentation.
F-Xavier

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page