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

["Randy Brukardt" <randy@rrsoftware.com>]

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