At 11:57 AM 9/23/98 -0400, Peter Shenkin wrote:
>On Sep 23,  5:46pm, Thorsten Ohl wrote:
>> Subject: Re: A rare behaivor of pointers
>...
>> The area where the undifined status hurts (me) most is the need to use
>> pointers as poor man's allocatable components in user defined types.
>> F95 helps a lot and F2K will (hopefully) be even better.
>
>Sorry, but why does it hurt you there especially?  I mean, when
>you allocate a user-defined type, you have to initialize all the
>components explicitly (F90) or implicitly (F95).  Why is this problem
>worse here than elsewhere?
>

I think the problem is with derived type variables that include pointers
and have a module that does the work on them.  The varying length
character string module is an example.  Variables are declared in user
routines
and then the module tries to do something with them.  But, the module
routines don't know whether or not they can release the storage
"associated" with the pointer because they can't tell if it has been
initialized or not.  A user thinks he's initializing a string variable
when he does something like
     v_l_s_thing = "starting_value"
but the defined assignment routine can't tell whether or not this is the
first use of the internal pointer.  So storage leaks.  

One solution is to have initializer routines that the user must call, but
people forget and there isn't a good way for the module to detect that.
Yes, forgetting is a case of people using the module incorrectly, but
it happens.

F2K will have magic initializer and destructor routines that can always
do the right thing (or at least always do something ;-} ) when a derived
type variable is created.

Dick Hendrickson



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