(j3.2006) Storage_size ??
Mon Jul 29 11:29:04 EDT 2013
On 7/27/13 6:08 AM, Robert Corbett wrote:
> On 07/26/13 10:43, Bill Long wrote:
>> suppose I have
>> Type :: x (M)
>> Integer,len:: M
>> Integer:: array(M,M)
>> What is returned by STORAGE_SIZE(xx) ?
>> Option 1: The size of a dope vector (since the implementation always
>> allocates components sized by type parameters on the heap, hence
>> represented by a dv).
We started by expanding the inside, but that lead to other problems. So
we switched to the more mechanical formula based on actual memory usage.
If the above declaration had been
type(x(4)) :: xx(2)
then storage_size(xx) would return loc(xx(2)) - loc(xx(1)). That would
be the size of the dope vector in this case.
This is a somewhat artificially simple example. Suppose there was an
integer,allocatable :: alloc(:)
and the allocations for xx(1)%alloc and xx(2)%alloc had different sizes.
Clearly the size of the dope vector is the only relevant measure for
>> Option 2: The size of one integer (m) + 16 * size of an integer = 17*4 .
>> (Even though this has no relationship to the contiguous memory layout
>> of xx.)
>> Option 3: Storage_size should not be applicable for parameterized
>> derived types. This is an oversight in the standard.
> I would say option 2, except that I would not include the size of the length
> parameter in the result. The result value is the size of element of an array
> whose dynamic type and type parameters are those of the actual argument
> corresponding to the dummy argument A. In our design of parameterized derived
> types (and design is all we have to date), the values of the
> type parameters are stored apart from the data. In an array, the type
> parameters are the same for every element and so there is no need for more than
> one copy of their values for the entire array.
Right. Basically a pointer into a type table where the type parameters
are stored. For us, the type table pointer is in the dope vector, hence
a DV representation. Similar to how polymorphic objects are handled.
Give the answers so far, it appears that the value returned is
implementation-dependent, but is always loc(xx(2)) - loc(xx(1)).
> Bob Corbett
> J3 mailing list
> J3 at mailman.j3-fortran.org
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
More information about the J3