In a message dated 1/13/00 1:59:49 PM, [log in to unmask] writes:
>Yeah, it's an unfortunate choice. Unfortunately, there are no
>fortunate choices. Suppose P1 and P2 are pointers, what should happen
>to ASSOCIATED(P1,P2) for
> P1 => array(10:9) ; P2 => array(10:8)
>or
> P1 => array(10:9) ; P2 => array(5:4)
>or
> P1 => array(1:2:-1); P2 => array(2:1)
>or
> P1 => array(2:1) ; P2 => other_array(2:1)
I suppose that part of the problem for zero sized objects is that with this
definition of associated you can allow some optimizations that are not
allowed for other definitions, i.e., the array descriptor can be a scalar
indicating that the size is zero and does not need an associated pointer in
the descriptor. The optimization crowd for Fortran would probably want that
optimization. Under this definition the "address" of a zero sized object is
effectively undefined. A full definition would introduce a detailed
definition of aliasing, something that is difficult to do in any language, par
ticularly if optimization is desired.
What might be a useful addition to Fortran, out of the probably infinite
number of useful additions, is a ZERO keyword for associated that in effect
returns the equivalent of
(size(a).eq. 0 and size(b) .eq. 0) .or. associated(a,b)
where the intent of the ZERO keyword is an explicit reminder to users of the
detailed semantics of associated, as this function can easily be written by
users once they recognize the problem.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|