(j3.2006) Storage_size ??

[Bill Long]

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)
>>
>> Endtype
>>
>>
>>
>> Type(x(4))::xx
>>
>>
>> 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 
additional component

    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 
this component.

>>
>> 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)).

Cheers,
Bill



>
> Bob Corbett
>>
>
> _______________________________________________
> 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