assignment aggregates in controlled types

assignment aggregates in controlled types

[sbelmont700]

hi,

Does anyone know what, if anything, the language say about the use of assignment aggregates during adjust/finalize procedures?  If you do something like this:

procedure Finalize (Object : in out T) is
begin
  Object := (x => 0);
end;

does not that create a temporary object on the RHS that is assigned (and adjusted) into the LHS, and then the RHS itself finalized by calling Finalize, and then it's finalization procedures all the way down?  For types that are not required to build-in-place, it's unspecified whether it is (right?), so presumably that's a valid behavior?  Is such behavior prohibited, expected, undefined, implementation-defined, or even mentioned in the LRM at all?

-sb

PS - no amount of spamming by the crazies will make this newsgroup any less valuable, please don't let it discourage anyone from participating.

Re: assignment aggregates in controlled types

[Jeffrey R. Carter]

On 2/23/20 2:23 AM, sbelmont700@gmail.com wrote:
> 
> Does anyone know what, if anything, the language say about the use of assignment aggregates during adjust/finalize procedures?  If you do something like this:
> 
> procedure Finalize (Object : in out T) is
> begin
>    Object := (x => 0);
> end;
> 
> does not that create a temporary object on the RHS that is assigned (and adjusted) into the LHS, and then the RHS itself finalized by calling Finalize, and then it's finalization procedures all the way down? 
This is perfectly safe, because it won't compile. You need to write

Object := (Controlled with X => 0);

The canonical behavior is to create a temporary, though it may be optimized 
away, and I have not heard of any exception for controlled types, so I would 
suggest avoiding such a construct. Have you tried experimenting to see what happens?

-- 
Jeff Carter
"My legs are gray, my ears are gnarled, my eyes are old and bent."
Monty Python's Life of Brian
81

Re: assignment aggregates in controlled types

[Randy Brukardt]

<sbelmont700@gmail.com> wrote in message 
news:7c74a973-e278-427c-bbda-f4c1ebf8fdef@googlegroups.com...

>Does anyone know what, if anything, the language say about the use of 
>assignment
>aggregates during adjust/finalize procedures?  If you do something like 
>this:
>
>procedure Finalize (Object : in out T) is
>begin
>  Object := (x => 0);
>end;
>
>does not that create a temporary object on the RHS that is assigned (and
>adjusted) into the LHS, and then the RHS itself finalized by calling 
>Finalize,
>and then it's finalization procedures all the way down?  For types that are 
>not
>required to build-in-place, it's unspecified whether it is (right?), so 
>presumably
>that's a valid behavior?  Is such behavior prohibited, expected, undefined,
>implementation-defined, or even mentioned in the LRM at all?

Controlled types are always required to be built-in-place, but 
build-in-place never applies to assignment statements (it's for 
*initialization* of an object). There is a permission to remove the 
temporary and/or the calls to Finalize and Adjust, but never a mandate. 
Ergo, if you use such an assignment in Finalize or Adjust, you are possibly 
making a recursive call. Which obviously isn't going to work.

So portable code needs to avoid any sort of full-item assignment in Finalize 
and Adjust. (Typically, Finalize and Adjust deal only with a handful of 
components anyway.)

It would be possible to define some sort of build-in-place analog for 
assignment statements, but it hasn't seemed an important enough problem to 
deal with. Note that build-in-place was originally defined to avoid a 
semantic problem: it was impossible to portably put an initialized object of 
a controlled type into a package specification: the Adjust routine would not 
yet be elaborated, so any attempt to do so would raise Program_Error. There 
is no workaround to avoid that short of putting the initialization itself 
into the body (and that would prevent declaring a constant). There's no such 
problem with assignment; one can always use component-at-a-time assignments 
as an alternative.

I don't recall ever having run into this problem in my programs, but that 
might be a style issue.

                                Randy.