* assignment aggregates in controlled types
@ 2020-02-23 1:23 sbelmont700
2020-02-23 11:07 ` Jeffrey R. Carter
2020-02-24 23:13 ` Randy Brukardt
0 siblings, 2 replies; 3+ messages in thread
From: sbelmont700 @ 2020-02-23 1:23 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: assignment aggregates in controlled types
2020-02-23 1:23 assignment aggregates in controlled types sbelmont700
@ 2020-02-23 11:07 ` Jeffrey R. Carter
2020-02-24 23:13 ` Randy Brukardt
1 sibling, 0 replies; 3+ messages in thread
From: Jeffrey R. Carter @ 2020-02-23 11:07 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: assignment aggregates in controlled types
2020-02-23 1:23 assignment aggregates in controlled types sbelmont700
2020-02-23 11:07 ` Jeffrey R. Carter
@ 2020-02-24 23:13 ` Randy Brukardt
1 sibling, 0 replies; 3+ messages in thread
From: Randy Brukardt @ 2020-02-24 23:13 UTC (permalink / raw)
<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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-02-24 23:13 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-23 1:23 assignment aggregates in controlled types sbelmont700
2020-02-23 11:07 ` Jeffrey R. Carter
2020-02-24 23:13 ` Randy Brukardt
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox