help / color / mirror / Atom feed
From: "Randy Brukardt" <>
Subject: Re: Why don't all initialising assignments use 'build-in-place' ?
Date: Sat, 25 Mar 2023 03:39:14 -0500	[thread overview]
Message-ID: <tvmbvj$2417c$> (raw)
In-Reply-To: tvc6j9$3gfe$

"Rod Kay" <> wrote in message 
> 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 
(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.


  reply	other threads:[~2023-03-25  8:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-21 12:06 Why don't all initialising assignments use 'build-in-place' ? Rod Kay
2023-03-25  8:39 ` Randy Brukardt [this message]
2023-03-26  5:10   ` Rod Kay
2023-03-26 10:41     ` Jeffrey R.Carter
2023-03-27  4:44       ` Rod Kay
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox