From rz48@rz.uni-karlsruhe.de  Thu Jul  4 11:10:56 1996
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id LAA16132 for <sc22wg5@dkuug.dk>; Thu, 4 Jul 1996 11:09:15 +0200
Received: from ry73.rz.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de 
          with SMTP (PP); Thu, 4 Jul 1996 11:06:13 +0200
Received: by ry73.rz.uni-karlsruhe.de (1.37.109.16/16.2) id AA054621171;
          Thu, 4 Jul 1996 11:06:11 +0200
Subject: Re: (SC22WG5.1119) Allocatable Components - User Input
To: martin@anduin.ocf.llnl.gov (Jeanne T Martin)
Date: Thu, 4 Jul 1996 11:06:11 +0200 (CES)
Cc: sc22wg5@dkuug.dk
In-Reply-To: <199607032056.WAA08441@dkuug.dk> from "Jeanne T Martin" at Jul 3, 96 01:42:00 pm
From: hennecke@rz.uni-karlsruhe.de
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Content-Length: 2499
Message-ID: <"nz11.rz.un.131:04.07.96.09.06.25"@rz.uni-karlsruhe.de>

According to Jeanne T Martin:
> >    We have been working with derived types containing allocatable
> > pointers. In some cases the ONLY reason we are using pointers is that
> > allocatable arrays are not permitted in a derived type. This leads
> > to what we consider inconsistent behavior of the = versus the =>
> > assignments. As stated in the Fortran Handbook p276, rule 14
> > "If a structure has a component with the POINTER attribute and the
> > structure is assigned a value using an instrinsic derived-type assignment,
> > POINTER ASSIGNMENT is used for each component with the POINTER
> > attibute." From our perspective this means that when you do a
> >    derived_type1 = derived_type2
> > assignment the pointer array inside the derived type is not
> > copied but acts like a => assignment instead. This has been very
> > confusing to us since if we wanted that we would have used
> >    derived_type1 => derived_type2
> > instead. To get a copy of derived_type2, we must go in by hand and
> > assign each of the elements of the derived type by hand
> >    derived_type1%pointer_array = derived_type2%pointer_array
> >    derived_type1%real_var      = derived_type2%real_var
> > and so on.

You might point out to these users that they can improve their codes NOW
(that is, not waiting for the TR) becasue F90 allows them to overload 
the intrinsic ASSIGNMENT(=) for the TYPE(MET_DATA) in the example module
MET_DEFINITION with a user procedure, which can do the copying they need. 
This would transparently change their line of code "U(1,1) = U(1,2)"
in the main program to behave as they expect. 

Best regards,
Michael

PS: Of course they have to take care about "garbage collection", e.g. 
    deallocating the old LHS pointers before allocating them at the size of
    the RHS pointers. This in turn may cause trouble with the UNDEFINED 
    pointer association status (will be solved by NULL() in F95).

 ======================================================================
  Michael Hennecke      http://www.uni-karlsruhe.de/~Michael.Hennecke/ 
 ----------------------------------------------------------------------
  University of Karlsruhe         RFC822: hennecke@rz.uni-karlsruhe.de 
  Computing Center (G20.21 R210)               No longer on BITNET :-(
  Zirkel 2  *  P.O. Box 69 80                 Phone: +49 721  608-4862 
  D-76128  Karlsruhe                               Fax: +49 721  32550 
 ======================================================================