(j3.2006) Comment concerning TEAM_TYPE
Tue Oct 8 00:56:21 EDT 2013
On 10/7/13 5:36 PM, Van Snyder wrote:
> For LOCK_TYPE and EVENT_TYPE, it is specified that all components have
> default initialization. This means that one can use the type
I share Bill's puzzlement at the idea that this might be useful.
In fact, I would go so far as to say that enabling the type constructor for
LOCK_TYPE was almost certainly inadvertent - I recall no discussion of this
point at all.
>It is desirable to be able to use the constructor, presumably giving a
>"never appeared in a FORM TEAM statement that was executed" value.
>Otherwise, an object with a TEAM_TYPE component cannot be initialized.
If nothing in TEAM_TYPE is default-initialised, there is no problem with partial
If everything in TEAM_TYPE is default-initialised, one does not need the
constructor at all.
One can enable full initialisation without the constructor by overloading the
type name with a generic name whose only specific is a function that returns an
unusable type. Some might think that slightly perverse.
>> > The TS ought to say explicitly that they all do have default
>> > initialization, or that there is at least one that does not, so users
>> > will know whether the type constructor can be used.
>> I assume that the default is always that things are not default
>> initialized, but that could be stated explicitly.
Everything not stated about the components of a derived type would not be
standardised. Depending on the wording, this would likely make any program
depending on said characteristics not conforming. This is a bit stronger than
"processor dependent", which makes said programs not portable instead of not
>It should be stated.
We should certainly state what we intend to standardise. Whether we intend to
standardise this I cannot say. Even if we do want to allow the structure
constructor to be used, perhaps that should only be permitted in an
initialisation, and not, for example, as an actual argument.
One might also wonder about the utility of such things as
I mean, this is bad enough with LOCK_TYPE but with TEAM_TYPE the results should
be hilarious. Some additional requirements along the lines of "the result of a
function reference shall not be of type TEAM_TYPE" might be worth considering.
While I thinking of strange things, this seems to be valid:
CLASS(*),POINTER :: a,b
TYPE(team_type),TARGET :: x
a => x
ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?
TYPE IS (team_type)
SYNC TEAM(b) ! b is a copy of a?
DEALLOCATE(b) ! Deallocating TEAM_TYPE is ok?
...perhaps we ought to consider forbidding TARGET with TEAM_TYPE too, otherwise
half of the constraints are pretty pointless. Or adding runtime requirements.
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3