It's pretty clear to me that using equivalence is clean - since I assume
you can isolate the equivalence logic inside a module, I personally don't
see a problem with it myself if it's part of the legacy code.
A question for compiler writers: could transfer() be made more efficient, so
that people could reasonably stop using equivalence for generic data
manipulation? Perhaps the call to transfer() could be analyzed by the parser
to prevent some of the inefficiencies? It sees a pity that there is a way to
do what we want in theory, but that doesn't work in practice. After all,
transfer() was created to facilitate data management, wasn't it?
Alvaro
-----Original Message-----
From: Fortran 90 List [mailto:[log in to unmask]] On Behalf Of
David Vowles
Sent: Thursday, March 11, 2004 5:03 PM
To: [log in to unmask]
Subject: Re: Data type "UNDEFINED"
Russell, Richard wrote:
This thread has already mentioned TRANSFER as an option to achieve
standard compliance. To be specific in respect of the above example the
following snippet demonstrates the use. You will immediately see the
disadvantages are (i) "movement" of data (as suspected by Richard in an
earlier message) and (ii) as a result it is necessary to repack the data
at the end of the routine in the event that the strings are altered.
REAL VECTOR(100)
CHARACTER*8 STRING1
CHARACTER*20 STRING2
...
!!! EQUIVALENCE (STRING1,VECTOR(1)), (STRING2,VECTOR(49))
! ... Unpack ...
STRING1 = TRANSFER(VECTOR(1:LEN(STRING1)), STRING1)
STRING2 = TRANSFER(VECTOR(49:LEN(STRING2)+48), STRING2)
.... Modify STRING1 & STRING2 ??
! .... Repack ...
VECTOR(1:LEN(STRING1)) = TRANSFER(STRING1,0.0,LEN(STRING1))
VECTOR(49:LEN(STRING2)+48) = TRANSFER(STRING2,0.0,LEN(STRING2))
--
David Vowles,
School of Electrical and Electronic Engineering,
The University of Adelaide,
Australia, 5005.
|