(j3.2006) Interop TR: Assumed-size actuals
Aleksandar Donev
donev
Tue Nov 16 00:04:57 EST 2010
Hello,
I finally found some time to look at the draft Interop TR. I can see
that it is a unfinished product, but here are some questions/comments:
1. There is a whole lot of complication with an attempt to allow
assumed-size arrays to be associated as actuals with assumed-rank
dummies. Why is this really important? In particular, we don't go
through such hoops for assumed-shape dummies, so why was it seen as
important to start jumping through hoops now? For the shape, it is said
it is [(size(array,i),i=1,rank(array))]. Should this not be rank-1? What
is the size along the last dimension?
2. An assumed-type dummy shall not correspond to actuals of an "exotic"
derived type (e.g., no type-bound procedures). Is this "dynamic type".
If so, it seems allowed to have a CLASS(*) actual and not be able to
verify anything until run-time: If the dynamic type is indeed exotic no
one will notice and no errors will be generated.
3. There is some weird insistence that the base_addr, elem_len and
version be in that order?!? Why and if there actually is a good reason
please put a note.
4. I personally hate the proposed "solution" for characters. When it
comes to voting again, count me or alternative (1), making elem_len
equal to the character length (and if we do add wchar_t we will have
another type identifier, different from char, so I do not see what the
problem would be).
5. Can someone please write an example of the macro CFI_DESC_T. The only
ways I know involve union or malloc and I am not sure they can be used
as type identifiers in declarations. I understand that one can make
CFI_DESC_T(5) expand to some opaque block-of-enough-bytes, but that
defeats the purpose since one can only use the object of type
CFI_DESC_T(5) via pointers and casts, as done in the example in Note
5.2, but one could not in fact do something like object.base_addr. Seems
extremely clunky to me which is why I was opposed to flexible array members.
6. In the routine CFI_initialize_cdesc, presumably different things
happen depending on whether it is assumed-shape, pointer or allocatable
array, i.e., all the fields are properly initialized?
7. I made the point several times that a routine such as
CFI_cdesc_to_bounds cannot be implemented. It only works for contiguous
objects, since strides do not have to be integer multiples of the
lem_length. At least Bill agreed with me and then promised to take it
out but it is back in again, with unmodified wording.
Thanks,
Aleks
--
Aleksandar Donev, Assistant Professor of Mathematics
Courant Institute of Mathematical Sciences
Office: 909 Warren Weaver Hall, New York University
E-mail: donev at courant.nyu.edu
Phone: (212) 992-7315; Fax: (212) 995-4121
Mailing address: 251 Mercer St, New York, NY 10012
Web: http://cims.nyu.edu/~donev
More information about the J3
mailing list