How change fortran associate target?

[S__MPay]

Say I want to define an associate s_yNext like this:

ascFS: associate ( s_yNext => darMatData(i) )

When i is increased how do I update the target of s_yNext ?

Actually the original code is:

s_yNext => status%darMatData(i, MATDATA_P1STRS+status%curveSection(i))

I want to avoid that long right side part by using associate. otherwise I could simply use s_yNext => darMatData

[Arjen_Markus]

Once the associate statement has been run, the associations are fixed (unless I misunderstand it :)), but nothing prevents you from using associate in a loop:

do i =1,size(status%darMatdata)
     associate( s_yNext => status%darMatData(i, MATDATA_P1STRS+status%curveSection(i))
     ... do the right thing
  end associate
enddo 

[S__MPay]

Thanks Arjen; Actually the value of status%curveSection(i) is also changed under specific circumstance.

Arjen Markus wrote:

Once the associate statement has been run, the associations are fixed (unless I misunderstand it :)), but nothing prevents you from using associate in a loop:

do i =1,size(status%darMatdata)
     associate( s_yNext => status%darMatData(i, MATDATA_P1STRS+status%curveSection(i))
     ... do the right thing
  end associate
enddo 

[jimdempseyatthecove · Accepted solution]

Fortran does (did?) have a feature called Statement Functions (look it up). Unfortunately, this feature is identified as obsolescent in Fortran 2008, 2003, and 95.

This leave you with coding as Arjen suggests,... or
using the Fortran PreProcessor and use a #define macro.

#define s_yNext status%darMatData(i, MATDATA_P1STRS+status%curveSection(i))

Jim Dempsey

[Arjen_Markus]

You can still use statement functions, but there have been ample problems with them and internal routines are a much better alternative.

That said, even if you use a statement function or an internal function, then you can not change the value - they are functions after all.

An alternative might be to use a pointer variable: s_yNext => ... and update the pointer whenever status%curveSection(i) changes. A bit tricky. Perhaps the macro is the "best" option ;).

[jimdempseyatthecove]

In the OP's case, S wanted a single token without an (argument, list). While a contained function could have access to MATDATA_P1STRS and status, it would not necessarily have the correct access to i. Note, in test code it does appear to access an indexing variable correctly (as indexed), but the standard states that the memory location of a loop control variable need only to be updated at the exit of the loop (when registerized). Therefore necessitating passing i as an argument: s_yNext(i)

Which is a code change and somewhat grammatically misleading (is the function to return i+1'th entry?).

>>but there have been ample problems

Coding is fraught with ample problems.

Jim Dempsey

[IanH]

jimdempseyatthecove wrote:
...While a contained function could have access to MATDATA_P1STRS and status, it would not necessarily have the correct access to i. Note, in test code it does appear to access an indexing variable correctly (as indexed), but the standard states that the memory location of a loop control variable need only to be updated at the exit of the loop (when registerized). Therefore necessitating passing i as an argument: s_yNext(i)

There is no such statement in the standard. 

An internal procedure (or associate statement, or whatever) that access a loop control index by host association will access the value of the index at the time the procedure is invoked.

[jimdempseyatthecove]

>>There is no such statement in the standard

Not explicitly, perhaps implicitly. Why then the admonishment:

The DO variable must not be redefined or become undefined during execution of the DO range.

The DO loop is controlled by an iteration counter, and not a comparison of the DO variable with a limit. So why then "must not be redefined"?

Jim Dempsey

[Steve_Lionel]

The standard certainly has no wording about memory location. But the prohibition against redefining the loop variable inside the loop allows an implementation to use a counted loop (some architectures have special instructions for that) rather than testing the value each time. The standard DOES say that the number of iterations is determined at the start of the loop processing.

That said, some compilers (I know the DEC compilers and maybe ifort) could tell when it was possible the program, contrary to the standard, assigned to the LCV and switched from a counted to a tested loop. A program that does this is not standard-conforming.