1. Forum
  2. Usenet
  3. COMP.LANG.ADA

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

    From Rod Kay@21:1/5 to All on Tue Mar 21 23:06:03 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Randy Brukardt@21:1/5 to Rod Kay on Sat Mar 25 03:39:14 2023
    "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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rod Kay@21:1/5 to Randy Brukardt on Sun Mar 26 16:10:33 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jeffrey R.Carter@21:1/5 to Rod Kay on Sun Mar 26 12:41:00 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Rod Kay@21:1/5 to Jeffrey R.Carter on Mon Mar 27 15:44:33 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)