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

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

[Rod Kay]

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.

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

[Randy Brukardt]

"Rod Kay" <rodakay5@gmail.com> wrote in message 
news:tvc6j9$3gfe$1@dont-email.me...
> 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 ?

(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.

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

[Rod Kay]

On 25/3/23 19:39, Randy Brukardt wrote:
> "Rod Kay" <rodakay5@gmail.com> wrote in message
> news:tvc6j9$3gfe$1@dont-email.me...
>> 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 ?
> 
> (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.
> 
> 
> 

    Thanks, Randy. I somehow imagined that build-in-place would be 
faster :/.

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


Cheers.

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

[Jeffrey R.Carter]

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

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

[Rod Kay]

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.