(j3.2006) Select Rank

[Rafik Zurob]

Hi Van

I think the other responses are assuming SELECT RANK would be used only 
with assumed rank entities.  But your email below is talking about using 
it with entities with compile-time-known rank.  This would be inconsistent 
with SELECT TYPE, which is only allowed with polymorphic selectors.

I dislike encouraging users to write code containing known dead branches. 
SELECT RANK for entities of known rank will do that.  Yes, static analysis 
options might warn the user about it, and the compiler will likely clean 
it up.  But is there a better way to address your use case?  For example, 
if all you need to do is change the first element of the array, wouldn't 
an assumed-size array do the trick?  Also, in another email, Tom suggested 
preprocessor macros.  I don't know of a compiler vendor that doesn't 
support them.  Is there a reason you're using Fortran's INCLUDE instead of 
the preprocessor?

Regards

Rafik

j3-bounces at mailman.j3-fortran.org wrote on 17/02/2015 07:37:04 PM:

> From: Van Snyder <Van.Snyder at jpl.nasa.gov>
> To: j3 at mailman.j3-fortran.org
> Date: 17/02/2015 07:37 PM
> Subject: Re: (j3.2006) Select Rank
> Sent by: j3-bounces at mailman.j3-fortran.org
> 
> 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
>