John Blair-Fish wrote:
>
> I do not quite understand the documentation in Metcalfe and Read and
> other books on the Transfer function. I am helping a user switches
> bytes around. In the old days I'd equivalence a character array to
> an integer. I want to do something like:
>
> character char1,char2,char3,char4,char5(4)
> integer idate
> read(1)char1,char2,char3,char4
> char5(1)=char4
> char5(2)=char3
> char5(3)=char2
> char5(4)=char1
> ires=transfer(char5,idate,[somethingelsesize])
>
> I can not find an example illustrating the transfer function.
>
Transfer(x,y):
it simply decodes the internal representation of x in memory
(the bits) as if its type was the type of y.
Anyway, equivalence is still a useful concept which should
be kept in the future FXXXX releases, at least for a few
cases like the equivalence between REAL and COMPLEX arrays.
The problem with transfer is that it makes a copy the
memory zones, which is not needed in most cases.
Also I would like to have something 'equivalent' to
equivalence for dummy arguments, in order to aliase
arguments in a standard way:
SUBROUTINE toto(a,b)
REAL :: a(:)
COMPLEX :: b(:)
EQUIVALENCE (a,b)
to say that a and b share in fact the same memory area
(the compilers could easily check if the calls are correct or not)
But perhaps it doesn't fit in the philosophy of data
abstraction in f90 (does transfer fit?) ?
--
+-----------------------------------+-----------------------------+
| Pierre Hugonnet | mail....CGG |
| | 1, rue Leon Migaux |
| Seismic Data Processing R&D | 91341 MASSY cedex |
| | FRANCE |
| COMPAGNIE GENERALE DE GEOPHYSIQUE | phone...(33/0) 164 47 45 59 |
| Massy processing center (France) | fax.....(33/0) 164 47 32 49 |
| http://www.cgg.com | [log in to unmask] |
+-----------------------------------+-----------------------------+
My opinions are not necessarily those of CGG
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|