Here's a sample of the code.  This seems to be behaving
according to my naive expectations - incrementing isds
by one every time and then using that incremented value
as the array index.

But, it is a valid point that I'm using an "iffy"
construct to avoid a very simple "isds = isds+1" statement
before each pointer assignment.  If my program later blows
up on me, I may go back and do just that.  Maybe I'm trying
to be too clever for my own good.

flt_data(add1(isds))%x => qa_data%wind_data%lo_wind_ns%value
int_data(add1(isds))%x => qa_data%wind_data%lo_wind_ns%count
flt_data(add1(isds))%x => qa_data%wind_data%lo_wind_ew%value
int_data(add1(isds))%x => qa_data%wind_data%lo_wind_ew%count

!******************************************************************
FUNCTION ADD1(IDATA_IN) RESULT(IDATA_OUT)
!******************************************************************

IMPLICIT NONE

INTEGER, INTENT(INOUT)    :: IDATA_IN
INTEGER                   :: IDATA_OUT

idata_in = idata_in + 1
idata_out = idata_in

RETURN
END FUNCTION ADD1

Catherine


James Giles wrote:

> Aleksandar Donev wrote:
> > Catherine Moroney wrote:
> >> Writing a function seems to work though.  Or is there a problem with
> >> this solution that I don't know?
> > Don't even open that bag of worms.
> > The short answer: Do not use a function for this, use a subroutine.
> > Functions are not guaranteed to be executed:
> > a=f(x)+f(x)
> > is x incremented twice or once, i.e., how many times is f really
> > called???
>
> This issue is problematical (and Aleks' example is one of the
> very few cases in which the answer is fuzzy).
>
> The issue involves two standard provisions.  First, when an
> expression is evaluated, an implementation is free to evaluate
> any mathematically equivalent expression instead (or, if it's
> a LOGICAL or CHARACTER expression, it is free to evaluate
> any logically or stringly(?) equivalent expression).  It is permitted
> to do this even if the alternative mathematical (logical, string)
> expression is *computationally* different.  So, in a statement
> like:
>
>    a = 0*int_f(x)
>
> The compiler is free to substitute the mathematically equivalent
> expression 0 (zero) for the original.  (There is some dispute
> about whether 0.0*real_f(x) is mathematically equivalent to
> 0.0 since it depends on whether you regard the semantics of
> IEEE NaNs to be mathematical or just computational).
>
> In any case, there are not a lot of mathematical identities that a
> compiler might apply that could eliminate a function reference
> and so, not need to evaluate that function.  Most compilers
> don't bother.  There are easier to discover optimizations
> that are more often useful.  Few expressions contain obvious
> instances of these shortcuts that can be detected at compile
> time and run-time tests usually cause the code to run slower.
> But, it is a kind of optimization of which you ought to be aware
> just in case.
>
> Now, the second case is the one Aleks mentioned above.  The
> standard requires that functions must not have any side effects that
> change the value of any other entity in the same simple statement.
> With that rule in place, the compiler can assume for
>
>    a = f(x) + f(x)
>
> that F() neither changes its argument (since that's used elsewhere
> in the expression), nor does it change A, nor does it have saved
> internal state that would cause F itself to deliver a different answer.
> Those assumptions are collectively considered sufficient to allow
> processors to evaluate F(x) just once and use the result twice.
>
> Unrelated to the above, if the function is declared PURE, there
> are additional optimizations the compiler can apply, but since
> PURE functions have no side-effects anyway, that's not relevant
> to the current discussion.
>
> Now, there are those that *claim* (and increasingly decline to
> even defend the claim) that functions might *never* be executed
> in standard compliant implementations.  Such claims always
> involve out of context quotations and careful disregard of other
> explicit requirements of the standard (for example, that "the
> value of a function reference is determined by execution of the
> function", a statement which is the *only* provision in the entire
> document which states how to evaluate a function).
>
> In real life you can usually count on side-effect in functions to
> work as you expect.  If you make sure that the usual mathematical
> identities (like multiplying by zero) don't apply to your code
> and that you don't call the same function with the same argument
> twice in the same expression, that "usually" can be reliably replaced
> with "always".  If a given compiler doesn't do that, demand your
> money back and post the description here or to the usenet newsgroup.
>
> --
> J. Giles
>
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies."   --  C. A. R. Hoare

--
-------------------------------------------------------------------------
Catherine Moroney            phone : (818) 393-3392
Jet Propulsion Laboratory    fax   : (818) 393-4802
MailStop 169-315             email : [log in to unmask]
4800 Oak Grove Drive
Pasadena, CA  91109-8099