(j3.2006) Vipul Parekh's post in comp-fortran-90

[Malcolm Cohen]

Like Tom, I am not seeing any issue here.  An allocatable component is not a
pointer component, and an allocatable variable is not a pointer variable.

This is visible in F2003, consider
   TYPE T
      INTEGER,ALLOCATABLE :: A
   END TYPE
   INTEGER,ALLOCATABLE :: X
   TYPE(T) Y
   Y = T(X)
   ! No problem, Y%A is unallocated.
   X = 23
   Y = T(X)
   ! Now Y%A is allocated.
   X = 17
   PRINT *,Y%A ! prints 23, not 17
   END

That is, it is exactly as Tom said, you never get an alias with ALLOCATABLE,
you get a copy.  The T(X) constructor does *NOT* blindly copy the descriptor
for component A from X!  If X is unallocated, it makes an unallocated
component; if X is allocated, it makes an allocatable component with the
value of X.  Deep copying.

This is entirely a non-issue.

> It might be necessary to add to the requirements for assignment to an
allocatable variable that it is deallocated if it has any allocatable
components.  This might be too strong.

I cannot fathom the confusion of mind which would lead to such a crazy
suggestion!

> But it's not obvious that scenarios using multiple recursively-connected
types don't still result in cyclic relationships.

On the contrary it is ENTIRELY obvious because ALLOCATABLEs are *not*
POINTERs and do not act like pointers.

> This will need some deep investigation.

Actually "deep copying", which is indeed what we have always had for
allocatable components.  No deep investigation necessary.

Cheers,
-- 
..............Malcolm Cohen, NAG Oxford/Tokyo.

-----Original Message-----
From: j3-bounces at mailman.j3-fortran.org
[mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Van Snyder
Sent: Thursday, June 1, 2017 5:49 AM
To: j3 <j3 at j3-fortran.org>
Subject: (j3.2006) Vipul Parekh's post in comp-fortran-90

This is a revision of a previous message, that had the defect that the
variable foo was not given the allocatable attribute.

Vipul Parekh posted a question in comp-fortran-90 that makes me believe we
need an interp concerning recursive relationships between types using
allocatable components.  His example was

  type :: t
    type(t), allocatable :: next
  end type t
  type(t), allocatable :: foo
  foo = t(foo)
  print *, 'Is foo%next allocated? ', allocated(foo%next)

For this example, I'd say the print statement ought to print F

But in this example

  allocate ( foo )
  foo = t(foo)

it appears that there is a cyclic relationship between foo and itself using
its next component.  It depends upon whether foo is deallocated before
t(foo) is evaluated.  If it's not, there is a cyclic relationship.  I
believe one of the goals of the initial design of the ALLOCATABLE attribute
was to prevent cyclic relationships.

New stuff:

        Tom Clune has pointed out that during the assignment the next
        component is deep-copied from the constructor to foo, so maybe
        there's no problem.

It might be necessary to add to the requirements for assignment to an
allocatable variable that it is deallocated if it has any allocatable
components.  This might be too strong.  For example, it would prevent
walking down a linked list using

  foo = t(foo%next)

A possibility for this example is to interpret it as

  type(t) :: temp
  allocate ( foo )
  call move_allocate ( foo, temp )
  foo = t(temp)

But it's not obvious that scenarios using multiple recursively-connected
types don't still result in cyclic relationships.

This will need some deep investigation.

Althogh I'm the one who proposed to allow recursive relationships between
types using allocatable components, maybe we ought to remove it.




_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3

________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________