Re: Construction initialization problem

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 5 Dec 2008 19:42:40 -0600, Randy Brukardt wrote:

>> But you cannot, without pointers and dynamic allocation. Welcome back to 
>> C++!
> 
> If you have to resort to a dynamically allocated component, just wrap it in 
> a holder container.

That does not help. The inner container will have to propagate its
constraint to the outer container. The only solution to this is to replace
the outer container's constraint (anonymous not null access discriminant)
with a pointer. Subsequently, that pointer cannot be a not-null pointer.

> Then there is no possibility of data loss or (visible) 
> dynamic allocation. It would be nice to have a way to access the object 
> directly in such a container (a problem that I am working on for Amendment 
> 2), but that is not a critical part to be able to do this.

Critical parts are:

1. an explicit use of heap
2. not-null constraint is lost

It is just C++ written in Ada.

>>> Access discriminants have a fairly high overhead in Ada (because of the
>>> possibility of coextensions), so unless you *need* coextensions, they 
>>> ought to be avoided.
>>
>> Do you mean space or time overhead?
> 
> Yes. :-)

Can you elaborate on this. Considering:

   type T1 is ...
   procedure F1 (Object : in out T1);

   type T2 (X : not null access T1'Class) is ...
   procedure F2 (Object : T2) is
   begin
       Object.X.F1; -- Accessibility checks here?

I hoped that the compiler should drop any checks because X is a not-null
discriminant.

>>> But the only time you must use a discriminant is
>>> if you have a discriminant-dependent component, and there is no 
>>> interesting
>>> way to make a component dependent on an access discriminant. So I'd 
>>> prefer
>>> to just avoid the discriminant.
>>>
>>> If you're using discriminants to stand in for a proper constructor, I say
>>> "don't!!" Use a constructor function as the language intends (and force 
>>> it
>>> with a (<>) if you need it).
>>
>> Oh no, been there. The problem arose from inability to write such a
>> function! You must be able to write an aggregate to return it from the
>> function. The components of the aggregate will have the constraints
>> impossible to spell.
> 
> The reason that we added extended return statements to the language is so 
> that you don't have to write the entire return thing as an aggregate. The 
> only reason you would have to do that is because you used a discriminant 
> rather than a component. If it hurts, *don't do that*!!

I don't see how a function may help here. Let us rewrite the stuff to
pointers as you suggest:

   type A is tagged limited null record;
   type A_Ptr is not null access all A'Class;
   type B is tagged limited record
      X : A_Ptr;
   end record;
   type C is new B with record
      Y : aliased A;
   end record;
   function Create return C is
   begin
      return Result : C do
         Result.X := Result.Y'Unchecked_Access;
      end return;
   end Create;

This will propagate Constraint_Error upon an attempt to create a C with
Create.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de