CVS difference for ais/ai-00083.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00083.txt

--- ais/ai-00083.txt	1999/11/19 00:43:43	1.6
+++ ais/ai-00083.txt	1999/12/10 01:13:30	1.7
@@ -283,3 +283,135 @@
 
 ****************************************************************
 
+!topic Controlled objects are created without any initialization nor adjust.
+!reference RM95-7.6(10)
+!reference RM95-7.6(21)
+!reference AI95-0083
+!from Bj=F6rn K=E4llberg 99-05-01
+!keywords Initialize, Adjust, Controlled, Aggregates
+!discussion
+
+In 7.6 (1-2) it is stated, that every object is initialized and finalized,
+and by the use of controlled types the user can gain additional control.
+However, since the binding interpretation AI95-0083, this is not true. It
+is possible to create controlled objects, that are neither initialized nor
+adjusted. This is a serious break of the abstraction and makes it very hard
+or impossible to use finalization for a number of purposes. One example is
+the example in the book Ada95 by John Barnes, page 302, where an attempt is
+made to keep a reference count.
+
+Consider a declaration where the object is assigned an initial value.
+
+Package A is
+     Type C_t is new controlled with
+     ...
+end A;
+
+with A; use A;
+package B is
+     O1 : C_t;
+     O2 : C_t := O1;
+     O3 : C_T := (C_t with .....)
+
+Above O1 is initialized. O2 is not initialized by 7.6(10) but is instead
+adjusted as part of the assignment operation. O3 is not initialized, but by
+the AI83 it is not adjusted either.
+
+The rationale behind AI95-0083 was to avoid program_error due to access of
+the subprogram ?Adjust? before elaboration. However, the same argument
+applies also to Initialize, so before AI83 it was never possibly to declare
+controlled objects in the same package specification as the type, if there
+are overriding subprograms for Initialize or Adjust. Now it is still
+impossible to declare objects, except if they are initialized with an
+aggregate expression. Apart from making Initialize less useful, it is also
+a break against the uniformity goal of Ada95.
+
+A possible solution would be to mandate that the objects subject to AI83
+should be initialized instead.
+
+A similar problem arises regarding aggregates. 7.6(17) states that in an
+assignment statement an anonymous object is created, into which the values
+are assigned. The target is finalized, this anonymous value is assigned
+into the target, and the anonymous object is initialized. Also in this case
+seems at least two very popular compilers use the AI83, and not adjust (nor
+initialize) the anonymous object. Thus, also the anonymous object is
+created without any initialization nor adjust.
+
+In order to construct reliable abstractions in the presence of controlled
+types some predicates like those in 7.6(1) are needed. However, as written,
+the interpretation is not quite clear.
+
+Is the intent that the following statements shall be true for every
+controlled object? (YES!) (Initialize, Adjust, Finalize means, that the
+corresponding primitive operations of the controlled object are called)
+
+-    Every controlled object is Initialized or Adjusted when created
+-    Every object is Finalized before being destroyed
+-    In the absence of an abort, Initialize or Adjust is always paired with
+a corresponding Finalize. In the presence of an abort, the corresponding
+Finalize operation may be called several times.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, December 07, 1999 10:01 PM
+
+I really dislike AI95-0083 for just the reasons given in the K=E4llberg note
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, December 08, 1999 2:08 PM
+
+Bjorn Kaelberg wrote:
+> ...
+> Is the intent that the following statements shall be true for every
+> controlled object? (YES!)
+
+No.  Aggregates (and objects initialized with an aggregate)
+undergo neither Initialize nor Adjust.  Since you can only write
+an aggregate when you have full visibility on the type, there
+is no abstraction-breaking going on here, since you could arbitrarily
+change any visible component anyway in that case.  By making the type
+private (or a private extension) you ensure that no aggregates
+will be written outside of the package region.
+
+> ...(Initialize, Adjust, Finalize means, that the
+> corresponding primitive operations of the controlled object are called)
+>
+> -    Every controlled object is Initialized or Adjusted when created
+> -    Every object is Finalized before being destroyed
+> -    In the absence of an abort, Initialize or Adjust is always paired with
+> a corresponding Finalize. In the presence of an abort, the corresponding
+> Finalize operation may be called several times.
+
+Finalize is paired with an Initialize, an Adjust, or an aggregate
+evaluation.  Initialize corresponds to initialization by default,
+Adjust corresponds to initialization by copy (from an object with its
+own independent finalize), and aggregate evaluation corresponds to
+component-by-component initialization.
+
+> /Bj=F6rn K=E4llberg
+
+Robert Dewar wrote:
+
+> I really dislike AI95-0083 for just the reasons given in the K=E4llberg note
+
+I don't understand this complaint.  Are you suggesting that aggregates
+should *not* be finalized, or that either Adjust or Initialize should
+be called on an aggregate before it is finalized?  Or perhaps are
+you simply complaining that we shouldn't "require" the optimization
+that enables the definition of deferred constants in the same package
+with a controlled type?
+
+I really don't see any viable alternatives at this point, even if
+some of us dislike AI-83 for aesthetic reasons.  There is existing code
+that uses aggregates to define controlled values, and these
+assume that Adjust is *not* performed on the aggregate before it
+gets used or finalized.  Personally, I find it intuitive that when I
+construct a value using an aggregate, I construct it exactly as I
+want it, not in some way that will require an Adjust before it
+gets used further or finalized.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent