ASSOCIATE...END ASSOCIATE vs pointers

[jond]

Now that ASSOCIATE...END ASSOCIATE construct is introduced with F2003 standard (and implemented in IVF), are there any reasons left to use pointers? My understanding is that use of pointers can be tricky due to possible memory-leak issues. Also according to Metcalf, Reid and Cohen (Fortran 95/2003 Explained) the new construct will allow higher performance. Is this true?

Thanks for any clarifications,
Jon

[Steven_L_Intel1]

I don't see any relationship between the ASSOCIATE construct and pointers. In my view they are entirely different things. I suppose that one might use POINTER as a way to do something ASSOCIATE does, but I rarely run across that in applications. How do you see this?

I would say that in most applications, POINTER can and should be replaced by ALLOCATABLE.

[Andrew_Smith]

Quoting - Steve Lionel (Intel)

I don't see any relationship between the ASSOCIATE construct and pointers. In my view they are entirely different things. I suppose that one might use POINTER as a way to do something ASSOCIATE does, but I rarely run across that in applications. How do you see this?

I would say that in most applications, POINTER can and should be replaced by ALLOCATABLE.

I frequently use pointers to simplify code where I would otherwise need to repeat deep references into derived types. It makes the code neater, but once you exceed maybe half a dozen lines of code using the pointer it becomes more desirable from a design point of view to move the code into a new subroutine instead and then the pointer is no longer needed.

Does use of local pointers in this way potentially degrade compiler optimisation? and does the associate construct improve this?

I can't find any help about this construct in the Intel help file. Does it require the "pointer" to be declared or does it automatically take on the type of the pointee?

Andy

[Steven_L_Intel1]

ASSOCIATE has no relationship at all with POINTER. Use of POINTER definitely can hurt optimization.

ASSOCIATE is a way of simplifying references in a block of code. See section 8.1.4 of the Fortran 2003 Standard.

Here's a couple of examples from the standard:

The following example illustrates an association with an expression.

ASSOCIATE ( Z => EXP(-(X**2+Y**2)) * COS(THETA) )
PRINT *, A+Z, A-Z
END ASSOCIATE

The following example illustrates an association with a derived-type variable.

ASSOCIATE ( XC => AX%B(I,J)%C )
XC%DV = XC%DV + PRODUCT(XC%EV(1:N))
END ASSOCIATE

The following example illustrates association with an array section.

ASSOCIATE ( ARRAY => AX%B(I,:)%C )
ARRAY(N)%EV = ARRAY(N-1)%EV
END ASSOCIATE

The following example illustrates multiple associations.

ASSOCIATE ( W => RESULT(I,J)%W, ZX => AX%B(I,J)%D, ZY => AY%B(I,J)%D )
W = ZX*X + ZY*Y
END ASSOCIATE

[jimdempseyatthecove]

Quoting - Steve Lionel (Intel)

ASSOCIATE has no relationship at all with POINTER. Use of POINTER definitely can hurt optimization.

ASSOCIATE is a way of simplifying references in a block of code. See section 8.1.4 of the Fortran 2003 Standard.

Here's a couple of examples from the standard:

The following example illustrates an association with an expression.

ASSOCIATE ( Z => EXP(-(X**2+Y**2)) * COS(THETA) )
PRINT *, A+Z, A-Z
END ASSOCIATE

The following example illustrates an association with a derived-type variable.

ASSOCIATE ( XC => AX%B(I,J)%C )
XC%DV = XC%DV + PRODUCT(XC%EV(1:N))
END ASSOCIATE

The following example illustrates association with an array section.

ASSOCIATE ( ARRAY => AX%B(I,:)%C )
ARRAY(N)%EV = ARRAY(N-1)%EV
END ASSOCIATE

The following example illustrates multiple associations.

ASSOCIATE ( W => RESULT(I,J)%W, ZX => AX%B(I,J)%D, ZY => AY%B(I,J)%D )
W = ZX*X + ZY*Y
END ASSOCIATE

Not knowing the internals of the compiler could you shed light on the internal implimentation?

Is ASSOCIATE implimented like a FPP macro expansion (inline text substitution)
.or.
Is ASSOCIATE implimented likethe newC+0x Lambda Function (call to local function with scope of main function but may be inlined depending on optimization desired)

Jim Dempsey

[Steven_L_Intel1]

It is emphatically NOT macro expansion. At first glance you might think it was, but this breaks down when you associate with array slices or structure components. It is not a function call either. You could, I suppose, think of it as a limited-scope POINTER that has type and shape and that comes into existence when the construct is entered and disappears on exit. Perhaps a better analogy would be that of a dummy argument associated with the expression but which allows assignment.

[jimdempseyatthecove]

I did not intend my statement to be interpreted a being like a FORTRAN function call. Rather it is like an ASM subroutine call to a stub routine, perhaps pasted after the end of the FORTRAN subroutine/function, where the called routine uses the base pointer (EBP/RBP) of the FORTRAN code (thus sees all local variables of caller), plus in the case of using slice of array, the use of an array descriptor constructed for that purpose.

>>analogy would be that of a dummy argument associated with the expression but which allows assignment.

When you have ASSOCIATE(Z=> SIN(X)+COS(Y)) whatever
Just how would you handle Z=12.345?

Strange as this may seem, the compiler could handle the above code generation (e.g. Z becomes a functor in C++ jargon and can point to a function returning SIN(X)+COS(Y) or alternately pointing at a function that returns 12.345. I do not know what the standard says or what the current implementation does.

When Z points to a slice of an array, then it will make sense to permit assignment.

Also, assuming your compiler writers are worth their salt, Z could potentially point to disjointed pieces of an array and not use a temporary (assuming Z isn't passed as an argument to a subroutine or function)

Jim Dempsey

[Steven_L_Intel1]

In the case of ASSOCIATE(Z=> SIN(X)+COS(Y)) , Z is not definable.