(j3.2006) Storage_size ??

Tobias Burnus burnus
Sat Jul 27 06:12:17 EDT 2013

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

I do not see a difference to automatic variables, which can (and often 
are) stack allocated and in contiguous memory. Using a dope vector, 
which contains the component via a pointer to a heap-allocated memory is 
an implementation choice.

(Actually, I had excepted that an implementation would use contiguous 
memory with stack allocation in this case. I have not studied the fine 
print of parameterized DT, but at a glance I don't see anything which 
prevents this. But using a DV seems to be also a reasonable choice.)

Thus, I read option 1 as: Return the size of the internal representation 
of type(x(...)), which - depending on the processor - can be 
len-dependent or not.

> 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 wonder whether the problem is really different to allocatable 
components. There you have the same problem, except that users expect 
that those components use some kind of descriptor (for scalars, it could 
be a simple variable to hold a pointer) and uses heap allocation.

I admit that parameterized derived types are more complicated as it 
depends on the implementation and the result might run against 
expectations of the user. Still, Option 1 seems to be the best to me. 
Maybe, a note could be added or expanded an existing one to cover this.


More information about the J3 mailing list