(j3.2006) Storage_size ??
Sat Jul 27 06:12:17 EDT 2013
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).
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