William F Mitchell writes:
 > Does the standard address what should happen when the SOURCE in a TRANSFER call
 > is a derived type with a POINTER component?

Not really.

 > In particular, I would like to be certain that if I transfer a structure to an
 > array of integers, and transfer that back to a variable of the same derived
 > type, then the pointer will still point to the same target.  I don't see anything
 > in the f95 standard that addresses the transfer of pointers,

Me neither.  I'd expect things in practice to work as you hope, but as
you say, the concept of the "value" of a derived type with a pointer
component is a bit evasive.  Its "clear" (well, as much as things tend
to be) that if you TRANSFER a pointer directly, you'll just be
transferring it's target - the arguments to TRANSFER are not described
as having the pointer attribute and therefore, any pointer actual
arguments are dereferenced.  Pointer components are a different
matter, though.

 > but I would hope that
 > it transfers the address or dope vector or whatever the pointer contains, as
 > opposed to dereferencing the pointer as is done in almost all other contexts.
 > The closest I can come to guaranteeing this is that (if everything is the right
 > size) "the value of TRANSFER(TRANSFER(E,D),E) shall be the value of E" but I'm
 > not sure what "value" means for POINTERS.

I'd hope and expect the same, but I can't definitively support it
based on the standard.

P.S. *CAVEAT EMPTOR*.  Beware of garbage collectors if you do anything
like this.  Turn off any garbage collection options that ytour
compiler might have.  You've effectively just "hidden" the pointer in
some non-pointer type.  A garbage collector might well conclude that
the target was no longer accessible by any pointer, and was thus a
candidate for garbage collection.  That's very much the kind of thing
garbage collectors do.  Or you could run into problems with schemes
where targets are moved around in memory and any pointers to the moved
targets are adjusted.  The later scheme is less common.  Indeed, I
don't know of any current Fortran implementations doing things like
that, but it has certainly happened in some implementations of some
languages (Lisp seems a likely candidate, though I'm not enough up
on the details of Lisp implementations to cite cases).

-- 
Richard Maine
[log in to unmask]



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%