This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ACATS c380004
Duncan Sands wrote:
Hi Richard, thanks for the informative reply. I think I am convinced.
Some comments on this: protected objects and tasks differ from the above record type in that
they are limited types: they can't be copied. I guess one reason for the compiler choosing to
use the maximal possible size for a record with a default discriminant is that copying is
simplified: just do a fixed size memory copy. This reason does not apply to protected and task
types since they can't be copied. However another reason for allocating the maximum size springs
to mind: it simplifies the creation of arrays (eg an array of tasks), since all members of the
array have the same size. Having arrays where each component has a different size is too
horrible to contemplate. On the other hand, I suppose arrays of protected objects and tasks could
be implemented as arrays of pointers to the actual tasks/protected objects, invisibly to the
programmer. Anyway, after thinking a bit about the problems involved I now have a lot more sympathy
for ACT's position! In fact I'm surprised their protest was rejected - why was it rejected?
An entry family is most naturally implemented with an array of queues,
and the task discriminants are mapped into the discriminants of the
enclosing record, which is why we use
the same implementation strategy for regular records and for task
records. So far so good.
However, in the case of protected types, an entry family can be
implemented with a single
queue, and pending requests on it can be kept ordered by index (if the
queue is long the
system is thrashing anyway!). In this case, the array implementation
suggested by the "family" is bogus, and the problem disappears. The ARG
feels that this is a preferable implementation anyway, and we will
probably adopt it when we revisit the implementation of protected types
for Ada2005.
In the dark old days, the GNAT compiler didn't allocate the maximum possible size for records with default discriminants. They changed it a some point, for efficiency reasons IIRC.
as far back as I can recall, we always allocated the maximum possible
size for mutable
discriminated records. That's basic: no under-the-covers dynamic
allocation.
Ed Schonberg