Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why don't all initialising assignments use 'build-in-place' ?

71 views
Skip to first unread message

Rod Kay

unread,
Mar 21, 2023, 8:06:04 AM3/21/23
to
Hello again,

I'm sure there must be a good reason. All I can think of is that it
may somehow break backwards compatibility wrt controlled types (a vague
stab in the dark).

Any thoughts ?


Regards.

Randy Brukardt

unread,
Mar 25, 2023, 4:39:18 AM3/25/23
to
"Rod Kay" <roda...@gmail.com> wrote in message
news:tvc6j9$3gfe$1...@dont-email.me...
(1) Didn't want to make work for implementers.
(2) You shouldn't be able to tell (since it is required for all cases
involved finalization). Finalization is the only way to inject user-defined
code into the initialization process.
(3) True build-in-place can be expensive and complex (especially for array
types).
(4) Build-in-place requires functions compiled to support it (must pass in
the place to initialize into). That might not be the case (especially if a
foreign convention is involved). Also see (3) - an implementation might have
a cheaper way to return some types that doesn't support build-in-place.

There's probably more, those are off the top of my head. If it is cheap, it
would be silly for an implementation to do anything else. (Don't ask what
Janus/Ada does. ;-) Otherwise, most people want the fastest possible code.

Randy.



Rod Kay

unread,
Mar 26, 2023, 1:10:33 AM3/26/23
to
Thanks, Randy. I somehow imagined that build-in-place would be
faster :/.

So using 'extended return' *everywhere* would decrease performance,
I guess.


Cheers.

Jeffrey R.Carter

unread,
Mar 26, 2023, 6:41:03 AM3/26/23
to
On 2023-03-26 07:10, Rod Kay wrote:
>
>    Thanks, Randy. I somehow imagined that build-in-place would be faster :/.
>
>    So using 'extended return' *everywhere* would decrease performance, I guess.

You seem to think that using an extended return requires building in place. This
is not required by the ARM.

"Built in place" is defined in ARM 7.6 (17.1/3-17.p/3)
(http://www.ada-auth.org/standards/aarm12_w_tc1/html/AA-7-6.html#I4005). An
initial value is required to be built in place when

1. The object (or any part of the object) being initialized is immutably limited
2. The object (or any part of the object) being initialized is controlled and
the initialization expression is an aggregate

In all other cases, it is up to the compiler to decide whether or not to build
in place. This holds regardless of the the kind of return statement used if the
initialization expression is a function call.

Thus the initialization of an immutably limited object is done in place even if
the initialization expression is

* an aggregate
* a function call with a simple return statement

while the initialization of an integer object may be by copy even if the
initialization expression is a function call with an extended return statement.

--
Jeff Carter
"An essential part of teaching Ada is not
the technical details, but the message of
software engineering."
Jean-Pierre Rosen
167

Rod Kay

unread,
Mar 27, 2023, 12:44:32 AM3/27/23
to
On 26/3/23 21:41, Jeffrey R.Carter wrote:
>
> You seem to think that using an extended return requires building in
> place. This is not required by the ARM.
>

Yes, I did rather think that. Appreciate the correction.

0 new messages