[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week
nmm1 at cam.ac.uk
Thu Jun 4 10:58:48 CDT 2009
On Jun 4 2009, Aleksandar Donev wrote:
>> That is a truly horrible hack!
>What is a truly horrible hack? I am puzzled why you are soo inspired to
>simply write emails that disagree without constructive things to offer
>in return. I offered at least three options above, and they are all
>different in subtle ways. ALLOCATABLE components are fundamentally
>different from pointer ones, especially in regards to what they mean in
>the context of "copy by value".
Look, Aleks, I explained that in the rest of the paragraph that you snipped.
Here is the context and what I said, with some extra explanation.
% > One way to resolve these issues is to specify that the
% > TYPE(MPI_Communicator) "is an interoperable type", or "does not have
% > pointer and allocatable components", or "does not have allocatable
% > components", etc. One has to decide what to do here. Again, using what
% > we did for TEAMs in coarrays might be useful (but here following the C
% > binding closely might be a better guiding principle).
% That is a truly horrible hack! The whole point about the semantics of
% communicators is that they DO behave as if they have such components.
% However, I am afraid that the best solution may end up being a horrible
% hack, so I am not saying that your idea shouldn't be considered.
What I was referring to is that, if you express the semantics of
communicators in terms of the property of a Fortran type, you find that
they have components that are semantically equivalent to pointers.
Attributes are obvious, but you can also access all outstanding transfers
through a communicator, and so on. One common property of ALL the things
you mentioned is that they don't allow pointer components, and specifying a
communicator to be like that (when its semantics are such that it has them)
is necessarily a horrible hack.
>My sole point is that it needs to be specified---just saying "opaque"
>derived type is insufficient in Fortran (I suspect also in C but I do
>not know that language well-enough).
I fully agree with that, but was responding to your suggestions of how.
To repeat, I wasn't disagreeing, but was saying that it isn't nice, not at
You are correct about C, and I do.
>> I may have missed another, so please tell me if so.
>I believe that what I am thinking of is a "pointer to an incomplete
>type", but do not have my C book at home today to check. It smells like
>void* but it is different in some subtle ways, which I likely do not
Ah. No, that's not a category of types, as such. It's all rather confused.
I described the three main categories in my previous posting, though 'void'
is not a type at all, let alone an incomplete one.
You won't find an accurate description of C's subtleties in any book that I
have heard of - and even the standards are not enough on their own - you
really need to have been following the standardisation discussions. I gave
up after C99, so am not in touch with the next one, though I have seen
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1 at cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
More information about the mpiwg-fortran