From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Why is the destructor called multiple times after I declare an object? Date: Tue, 12 Jan 2016 14:21:05 -0600 Organization: JSA Research & Innovation Message-ID: References: <293c58ac-4ebd-488a-abcc-b6e88811eec8@googlegroups.com> <871t9ogevj.fsf@theworld.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1452630066 4572 24.196.82.226 (12 Jan 2016 20:21:06 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 12 Jan 2016 20:21:06 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:29109 Date: 2016-01-12T14:21:05-06:00 List-Id: "Dmitry A. Kazakov" wrote in message news:n72hag$bjq$1@gioia.aioe.org... > On 12/01/2016 00:44, Randy Brukardt wrote: >> "Dmitry A. Kazakov" wrote in message >> news:n715oq$fae$1@gioia.aioe.org... >>> On 2016-01-11 19:17, Bob Duff wrote: >>>> Brian Drummond writes: >>>> >>>>> Somehow I expected "extended return" to allocate space and "build in >>>>> place" during the execution of the return statement. >>>> >>>> Build-in-place is done for return of immutably-limited types, >>>> whether or not the extended return syntax is used. >>> >>> But you can leave one return statement on an exception, catch the >>> exception, and then return through another return statement, with other >>> discriminants and even other type of the result (if it is class-wide). >>> >>> Therefore the result can be potentially allocated and reallocated any >>> number of times. In which sense is this behavior 'in-place'? >> >> "Build-in-place" means simply that there is no temporary object, the >> object >> is created directly in its final resting place (that is the memory where >> it >> will live during its existence). >> >> Whatever amount of effort it takes to figure out that final resting place >> is >> not part of the equation. > > Yes, but you said 'no temporary object' which is untrue because a return > statement creates exactly such an object. You could even use this object > in order to create another one: > > return Candidate_1 : T (Size => 1) do > Size := Candidate_1.Get_Required_Size; > raise Try_Again; > end return; > exception > when Try_Again => > return Candidate_2 : T (Size => Size) do > ... > end return; > > Since Ada lacks proper user-defined constructors one cannot claim that > Candidate_1 was not fully constructed. Even its Initialize was through. But this is *not* a temporary object. The final object might change identity in such a scenario, but Candidate_1 and Candidate_2 are the *same* object, with different properties. The various limitations on using a function call as the parent part of an extension aggregate exist specifically because of this effect. For a inherently limited type (the kind that requires build-in-place), the location of the object is part of its identity, argubly the most important part. (I realize that you might be defining "object" in your own way, which as always is irrelevant; I'm using the definition of "object" and "temporary object" as used in the Ada Standard.) Randy.