- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All;
Is it allowable to have a module with declared allocatable arrays used by the main program where they are allocated and then pass them to a subroutine where they have an assumed size? It would look like this:
Program Main
Use Allocs
Allocate(x(npts))
Call Sub1(x)
End Program Main
where the Allocs module would be:
Module Allocs
Real,allocatable,dimension(:) :: x
End Module Allocs
and the sub would be:
Subroutine sub1(x)
Dimension x(*)
...so something with x inside its declared number of points range ...
End Subroutine sub1
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, this is fine, Once the array is allocated, you can use it like any other array.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you, Sir!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Chris,
Steve may have overlooked this (or I could be wrong on this)
Your subroutine sub is not inside the (optional) contains section of your module. As such, the program procedure has no interface for sub. While it will pass the base address of the array as a dummy, it knows not to pass the size.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As it will for any external subroutine with an implicit interface, the caller will only pass the base address of an assumed-size array argument. Likewise, the intrinsic SIZE is not allowed to be used in the external subroutine to to obtain the size along the last dimension of such an argument. Thus, given the following subroutine
subroutine sub(x,a,b) implicit none real x(*), a(2), b(3) print *,size(x) end subroutine
the compiler rejects it with the error message
sub.f90(4): error #6585: SIZE of array is not computable. [SIZE] print *,size(x)
Therefore, Chris H. should not run into any trouble on account of this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As the size of the assumed size array is not passed as a hidden argument...then, imho, "assumed-size" would be a misnomer. A more appropriate term would have been "indeterminable-size" or "unknown-size" or other synonym.
Where as a rank 1 "assumed-shape" assumes the size.
Steve, why did the standards committee choose these terms?
BTW, I find it humorous that the adjective assumed definition is: Used in a manner intended to deceive
As opposed to one of the verb definition of assume: To receive
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Assumed-size has been in the standard since F77, some 30 years before I joined the committee. However, I think the term is appropriate in that the called procedure assumes it knows what the size of the passed array is. Before F77, programs would dimension array dummy arguments as (1) for this, since compilers at the time mostly didn't do bounds checking. I remember that VAX FORTRAN would treat (1) the same as (*), but DEC Fortran 90 did not, resulting in quite a few complaints from users.
If you want to quibble about terms, how about "adjustable arrays", where the bounds are expressions that can include other dummy arguments, COMMON or module variables?
I will agree that "assumed shape" seems a bit of an oddball here. Again, this term was created (for F90) well before I joined the committee - I keep catching myself mixing up assumed-shape and deferred-shape that have the same syntax but different semantics. I would probably have preferred "passed-shape" or something like that for assumed-shape, but they didn't ask me.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks, Steve. I wasn't trying to attribute the nomenclature to activities you personally had with the committee. Rather to solicit any information as to any internal discussion on the subject matter.
With interfaces and bound checking the choice of array(*).
I do have a gripe with the IVF documentation
The size of the array is assumed from the actual argument associated with the assumed-size dummy array as follows: If the actual argument is an array of type other than default character, the size of the dummy array is the size of the actual array. If the actual argument is an array element of type other than default character, the size of the dummy array is a + 1 - s, where s is the subscript order value and a is the size of the actual array.
This the size of the dummy argument is a functional property of the dummy argument. Seeing that the size is not determinable via size(x), ubound(x), print *,x, etc... while usable as array(index) erroneously with index out of bounds (not available to bounds checking), the description in the IVF reference guide (and lack of bad sample code), is less than adequate.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue here is that while the standard says what the extent of the dummy is, there is no mechanism specified to make that info available and the standard itself says you may not use SIZE(), etc., on an assumed-size array. It is up to the programmer to ensure that bounds are not exceeded. There do exist compilers that can pass extra, hidden info about the effective argument and can do checks against those, but this creates a compatibility issue with previously compiled code. Even then, these compilers do so only for error checking and you still can't inquire about the extents.

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