(j3.2006) Select Rank

[Tom Clune]

Hi Van,

An expanded ability to work with assumed rank arrays is definitely something I would be interested in pushing for F2020.   SELECT RANK would be a major element of that feature set.

I am curious though if there is a reason that you could not accomplish your goals for this specific case using a preprocessor?   Aside from the understandable agenda of using pure Fortran that is.

We typically write such include files using a macro __DIMS__.  In the excternal code one sets the value of __RANK__.  E.g.

#define RANK 3

Then in the (cpp) include file you have:

#if __RANK__ == 0
#define __DIMS__
#elif __RANK__ == 1
#define __DIMS__ (:)
#elif __RANK__ == 2
#define __DIMS__ (:,:)
#elif __RANK__ == 3
#define __DIMS__ (:,:,:)
#endif

?

! here we declare the array

real :: array __DIMS__


Cheers,

- Tom




On Feb 17, 2015, at 7:37 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> On Tue, 2015-02-17 at 23:27 +0000, Bill Long wrote:
>> Does it really solve an existing problem?
> 
> This came up for me in a case involving an include file.
> 
> It had been doing things that only involved the entire array.  Then a
> requirement came along to do things to individual elements (the first
> element, in array element order, in particular).
> 
> The include file is used in places with different ranks, but
> (necessarily) always the same name.  In this case, the entity whose rank
> is selected would not be an assumed-rank entity.  So, presumably, the
> processor would optimize away all but one branch in each of the included
> instances.  Hopefully, we wouldn't prohibit a rank-3 branch of a SELECT
> CASE construct if the <selector> is actually rank-one, and not assumed
> rank.
> 
> The alternatives to a SELECT RANK construct in this case are:
> 
> 1. Make separate include files, one for each rank, and change all the
> INCLUDE statements.
> 
> 2. A kludge involving C_LOC and C_F_Pointer.  The kludge requires F08
> support, since F03 didn't allow arrays as arguments to C_LOC.  So the
> kludge can't even be done without either F08 support, or SELECT RANK.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150217/a8b8d3a1/attachment.html