(j3.2006) Comment concerning TEAM_TYPE
Tue Oct 8 23:25:05 EDT 2013
Now, yesterday I wrote
> If everything in TEAM_TYPE is default-initialised, one does not need
> the constructor at all.
Which is where Van started to object saying that no, the constructor was
But as we see,
"An object has default initialization if it is of a type that has default
and therefore the constructor is unnecessary in the context we are talking
>I don't see
>I don't understand the objection to simply saying
I might or might not object to "simply saying" one thing or another, what I do
object to is making decisions on false premises. The idea that the constructor
is *NECESSARY* is false.
Whether we want to be dynamically creating "null or undefined team objects that
are not variables", or whether we want to permit named constants that are "null
or undefined team objects" is a separate discussion. And actually maybe
team_type is hunky dory but event_type has problems if we allow that. The
question is here is how hard the facilities are going to be nailed down, and
there are many considerations in that, e.g.
(a) language elegance (!)
(b) implementation overhead
(d) robustness in the face of errors
(e) resistance in making errors in the first place.
All of these are important, but in my view in parallel programming (d) and (e)
are very important indeed, and that is why I am focussing on the limitations.
The more we limit how these things are used, the greater the likelihood that
they will be used correctly.
Van has already made his case that it is convenient to be able to embed
TEAM_TYPE in larger types, and convenient to be able to fully initialise the
larger type object. At the moment (N1983) the latter is not permitted.
Permitting it would seem to require either that we allow constructors for
TEAM_TYPE, allow named constants of type TEAM_TYPE, or that we permit the value
for a nonancestor component to be omitted if all of its subcomponents are
default-initialised. Now *if* we want to permit full initialisation of a type
containing a TEAM_TYPE subobject, and *if* we are all ok with dynamically
creating non-variable values of type TEAM_TYPE then allowing the constructor is
certainly the simplest of those ideas, but it is not the only course open to us.
................................Malcolm Cohen, Nihon NAG, Tokyo.
More information about the J3