(j3.2006) Is 12.5.2.5p2 really necessary?

[Tom Clune]

In particular, it is often useful to produce a report on such information in an organized fashion.

E.g. I would like to have a report that shows memory usage (high-water mark, average, and/or instantaneous) for each component  of a complex simulation.    Being aware of which part of the system is stressing memory consumption can allow for a more timely improvement and prevent misdiagnosis when the proverbial straw-that-broke-the-camel?s back is in an otherwise modest model component.

To this end we would like to register each (significant) allocation and deallocation with additional metadata about the context.  

I would respond to Van, though, that in a perfect world, this is probably a better case for a templates than a change to the rules for polymorphism.    If SIZEOF() were a type-bound procedure (and intrinsics had type-bound procedures) then this might be a good case for polymorphism.   

Cheers,

- Tom


> On May 9, 2016, at 6:38 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> On Mon, 2016-05-09 at 12:13 +0000, Bill Long wrote:
>> On May 6, 2016, at 7:10 PM, Van Snyder <Van.Snyder at jpl.nasa.gov>
>> wrote:
>> 
>>> A colleague tried to write a simple routine that would compute the size
>>> in bytes of an array (to track memory usage), deallocate it, test the
>>> status, and print a message if failure occurred.  Rather than writing
>> 
>> Rather than trying to do something obtuse why not just use Fortran:
>> 
>> mysize = storage_size(x)*size(x)
>> deallocate(x, stat=is)
>> if (is == 0) then
>>    used_space = used_space - mysize
>> else 
>>    print *, ?failure to deallocate array"
>> end if
> 
> Something you need in hundreds of places is the poster child for
> subroutines.
> 
> A subroutine that doesn't care about the type or rank of its argument is
> the poster child for polymorphism and assumed rank.
> 
>> Cheers,
>> Bill
>> 
>> 
>>> one for every type and kind, he tried to make the dummy argument
>>> unlimited polymorphic.
>>> 
>>> This fell afoul of 12.5.2.5p2:
>>> 
>>>       The actual argument shall be polymorphic if and only if the
>>>       associated dummy argument is polymorphic, and either both the
>>>       actual and dummy arguments shall be unlimited polymorphic, or
>>>       the declared type of the actual argument shall be the same as
>>>       the declared type of the dummy argument.
>>> 
>>> Is this paragraph really necessary?  It seems that the object-oriented
>>> system ought to work just fine without it, albeit with some more words
>>> to describe how a dummy argument can be allocated if the actual
>>> argument's declared type is compatible with but not necessarily
>>> identical to the dummy argument's declared type.  The result would of
>>> necessity be that the dynamic type of the allocated entity is type
>>> compatible with the declared type of the actual argument if the actual
>>> argument is polymorphic, and the same type if it's not.  If there is no
>>> type spec in the allocate statement, the allocated type is the declared
>>> type of the actual argument.    Everything else, including deallocation,
>>> ought to work without additional explanation.
>>> 
>>> Processors might endure some complication in creating descriptors to
>>> connect polymorphic dummy arguments to nonpolymorphic actual arguments,
>>> or actual arguments whose declared types are type compatible rather than
>>> identical.  The "type" member of the CFI_cdesc_t struct ought to serve
>>> for this purpose.  Because having a polymorphic dummy argument requires
>>> an explicit interface, a processor would know where this is required.
>>> 
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> Bill Long
>> longb at cray.com
>> Fortran Technical Support  &                                  voice:
>> 651-605-9024
>> Bioinformatics Software Development                     fax:
>> 651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>> 
>> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 	<Thomas.L.Clune at nasa.gov>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC		
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635













-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160510/b558a2a0/attachment-0001.html