CVS difference for ais/ai-00363.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00363.txt

--- ais/ai-00363.txt	2004/03/02 00:34:09	1.3
+++ ais/ai-00363.txt	2004/04/30 02:35:39	1.4
@@ -514,3 +514,48 @@
+From: Randy Brukardt
+Sent: Wednesday, April 21, 2004  5:25 PM
+The problem with part 2 of AI-363 (as discussed at Phoenix) is that there
+was performance incompatibilities. (This part says that certain types are
+allocated as unconstrained on the heap, in order to avoid privacy breaking.)
+I've been thinking about a related problem, which is implementing the
+containers library as specified. That specification prevents the use of
+constrained elements for the definite packages, which means that they can't
+allocated from the heap individually or be aliased.
+Because of Janus/Ada's code sharing, each component of a generic private
+type is allocated individually by the compiler. That allocation is of course
+unconstrained. I'd like to replace that by an explicit allocation (so that
+we can take advantage of moving the pointers instead of the elements for
+inserts and sorts), but to do so, I have to have a way to allocate
+unconstrained objects on the heap. The only technical reason that I can't do
+that is that Ada doesn't allow it (ignoring the issue of access subtypes,
+which is taken care of by AI-363, part 1, which had general support).
+So I was thinking of adding a representation attribute to our compiler:
+    type A_Ptr is access all Element_Type;
+    for A_Ptr'Designates_Unconstrained use True;
+All this actually does in Janus/Ada is change the value of the 'Constrained
+flag passed to assignment thunks. (A very easy change.) This would just be
+supported on definite subtypes, it makes no sense for indefinite subtypes.
+This seems like a generally useful idea (esp. in the absence of AI-363 pt.
+2). It doesn't really help with private types, but a similar idea could be
+applied there:
+    type Some_Private is private;
+    type Some_Private (Disc : Integer := 100) is record ...
+    for Some_Private'Unconstrained_when_Allocated use True;
+which would avoid compatibility problems. The only annoyance is the usual
+problem: you'd prefer this to be the default case. Of course, with more
+incompatibility, we could make this the default, and then use the attribute
+to force back to the old way if there is trouble.

Questions? Ask the ACAA Technical Agent