* Extended return question @ 2008-07-10 2:11 Dale Stanbrough 2008-07-10 7:18 ` Georg Bauhaus 2008-07-10 14:37 ` Robert A Duff 0 siblings, 2 replies; 16+ messages in thread From: Dale Stanbrough @ 2008-07-10 2:11 UTC (permalink / raw) The purpose of an extended return is to create the values in-situ without copying. However an exception in the middle of the extended return seems to indicate otherwise (using Gnat). Is this the expected behaviour, or is my understanding of the extended returns correct? Thanks, Dale ------------------------------------------------- with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; procedure Returning_Large_Objects is type List is array (1..4) of Integer; function Extended_Return_Error (Raise_Exception : Boolean) return List is begin return L : List do L (1) := 1; L (2) := 2; if Raise_Exception then raise Constraint_Error; end if; L (3) := 3; L (4) := 4; end return; end; Destination : List; ------------------------------- procedure Put (Item : List) is begin for i in Item'range loop Put (Item (I)); end loop; New_Line; end; begin -- run normally, no exception Destination := (others => 0); Put (Destination); Destination := Extended_Return_Error (false); Put (Destination); -- displays 1 2 3 4 as expected --------------------------------- -- run with exception in middle Destination := (others => 0); Put (Destination); begin Destination := Extended_Return_Error (true); exception when others => null; end; Put (Destination); -- displays 0 0 0 0, i expected 1 2 0 0 -- the exception seems to have affected statements -- that precede it end Returning_Large_Objects; -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 2:11 Extended return question Dale Stanbrough @ 2008-07-10 7:18 ` Georg Bauhaus 2008-07-10 7:32 ` Dale Stanbrough 2008-07-10 14:37 ` Robert A Duff 1 sibling, 1 reply; 16+ messages in thread From: Georg Bauhaus @ 2008-07-10 7:18 UTC (permalink / raw) Dale Stanbrough wrote: > The purpose of an extended return is to create the values in-situ > without copying. _Limited_ objects can be initialized in situ by an aggregate or function call ... :-) -- Georg Bauhaus Y A Time Drain http://www.9toX.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 7:18 ` Georg Bauhaus @ 2008-07-10 7:32 ` Dale Stanbrough 2008-07-10 15:24 ` Adam Beneschan 2008-07-10 23:20 ` Randy Brukardt 0 siblings, 2 replies; 16+ messages in thread From: Dale Stanbrough @ 2008-07-10 7:32 UTC (permalink / raw) Georg Bauhaus wrote: > Dale Stanbrough wrote: > > The purpose of an extended return is to create the values in-situ > > without copying. > > _Limited_ objects can be initialized in situ by an aggregate > or function call ... :-) Ah, thanks. I had misread John Barnes comments on this. Why such a restriction? Why not allow it for all extended returns on all types? Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 7:32 ` Dale Stanbrough @ 2008-07-10 15:24 ` Adam Beneschan 2008-07-10 23:56 ` Dale Stanbrough 2008-07-10 23:20 ` Randy Brukardt 1 sibling, 1 reply; 16+ messages in thread From: Adam Beneschan @ 2008-07-10 15:24 UTC (permalink / raw) On Jul 10, 12:32 am, Dale Stanbrough <MrNoS...@bigpoop.net.au> wrote: > Georg Bauhaus wrote: > > Dale Stanbrough wrote: > > > The purpose of an extended return is to create the values in-situ > > > without copying. > > > _Limited_ objects can be initialized in situ by an aggregate > > or function call ... :-) > > Ah, thanks. I had misread John Barnes comments on this. Why such a > restriction? Why not allow it for all extended returns on all types? For nonlimited types, function calls work the same way they've always worked since Ada 83. The function call builds an anonymous object. In your example, since you're using an assignment, the anonymous object is then assigned into Destination. But of course, if the function raises an exception, the assignment never takes place. This isn't too different from this situation, which has always existed since Ada 83: Destination := (1 => Func1, 2 => Func2, 3 => Func3, 4 => Func4); If Func1 and Func2 complete normally, but Func3 raises an exception, *no* elements of Destination are changed. Extended return is no different. Function calls still involve anonymous objects to hold the function result, and extended return doesn't change that. Hope this helps, -- Adam ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 15:24 ` Adam Beneschan @ 2008-07-10 23:56 ` Dale Stanbrough 0 siblings, 0 replies; 16+ messages in thread From: Dale Stanbrough @ 2008-07-10 23:56 UTC (permalink / raw) Adam Beneschan wrote: > Hope this helps, Yes it does. Thanks for the info everyone. Back on the right track again. Dale -- dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 7:32 ` Dale Stanbrough 2008-07-10 15:24 ` Adam Beneschan @ 2008-07-10 23:20 ` Randy Brukardt 2008-07-11 0:03 ` Adam Beneschan 1 sibling, 1 reply; 16+ messages in thread From: Randy Brukardt @ 2008-07-10 23:20 UTC (permalink / raw) "Dale Stanbrough" <MrNoSpam@bigpoop.net.au> wrote in message news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au... > Georg Bauhaus wrote: > >> Dale Stanbrough wrote: >> > The purpose of an extended return is to create the values in-situ >> > without copying. >> >> _Limited_ objects can be initialized in situ by an aggregate >> or function call ... :-) > > > Ah, thanks. I had misread John Barnes comments on this. Why such a > restriction? Why not allow it for all extended returns on all types? Build-in-place is *allowed* for all objects; it is only *required* for types that always have to be limited (now known as "immutably limited types" (see AI05-0052-1). The reason it is not required is that the function could be used in an assignment statement, and in that case, it doesn't make sense to require build-in-place. And trying to have a function that works both ways could be expensive to implement (the calling conventions are very different). Randy. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 23:20 ` Randy Brukardt @ 2008-07-11 0:03 ` Adam Beneschan 2008-07-11 0:50 ` Robert A Duff 0 siblings, 1 reply; 16+ messages in thread From: Adam Beneschan @ 2008-07-11 0:03 UTC (permalink / raw) On Jul 10, 4:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Dale Stanbrough" <MrNoS...@bigpoop.net.au> wrote in message > > news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au... > > > Georg Bauhaus wrote: > > >> Dale Stanbrough wrote: > >> > The purpose of an extended return is to create the values in-situ > >> > without copying. > > >> _Limited_ objects can be initialized in situ by an aggregate > >> or function call ... :-) > > > Ah, thanks. I had misread John Barnes comments on this. Why such a > > restriction? Why not allow it for all extended returns on all types? > > Build-in-place is *allowed* for all objects; it is only *required* for types > that always have to be limited (now known as "immutably limited types" (see > AI05-0052-1). Where does the RM say that build-in-place is allowed for all objects? The only place I can see that refers to build-in-place for nonlimited objects is 7.6(21), and that permission seems to apply only to controlled objects. Also, the language there says that if a function call is assigned into a target object, an anonymous object doesn't need to be created if the value of the function call can be "safely" created in the target object. But "safely" isn't defined. If the function could create part of the target object and then terminate on an exception, as in Dale's original example, is that considered "unsafe", which would mean build-in-place isn't allowed for this function call? If it doesn't mean that, what does "safely" mean? -- Adam (Note: I will not see any response until 7/22) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-11 0:03 ` Adam Beneschan @ 2008-07-11 0:50 ` Robert A Duff 0 siblings, 0 replies; 16+ messages in thread From: Robert A Duff @ 2008-07-11 0:50 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > On Jul 10, 4:20 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: >> "Dale Stanbrough" <MrNoS...@bigpoop.net.au> wrote in message >> >> news:MrNoSpam-BCD9C2.17322110072008@news-server.bigpond.net.au... >> >> > Georg Bauhaus wrote: >> >> >> Dale Stanbrough wrote: >> >> > The purpose of an extended return is to create the values in-situ >> >> > without copying. >> >> >> _Limited_ objects can be initialized in situ by an aggregate >> >> or function call ... :-) >> >> > Ah, thanks. I had misread John Barnes comments on this. Why such a >> > restriction? Why not allow it for all extended returns on all types? >> >> Build-in-place is *allowed* for all objects; it is only *required* for types >> that always have to be limited (now known as "immutably limited types" (see >> AI05-0052-1). > > Where does the RM say that build-in-place is allowed for all objects? > The only place I can see that refers to build-in-place for nonlimited > objects is 7.6(21), and that permission seems to apply only to > controlled objects. > > Also, the language there says that if a function call is assigned into > a target object, an anonymous object doesn't need to be created if the > value of the function call can be "safely" created in the target > object. But "safely" isn't defined. If the function could create > part of the target object and then terminate on an exception, as in > Dale's original example, is that considered "unsafe", which would mean > build-in-place isn't allowed for this function call? If it doesn't > mean that, what does "safely" mean? For: X := F(...); the language rules require that X not be modified in case of exceptions in F. Of course the type of X is nonlimited here. - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 2:11 Extended return question Dale Stanbrough 2008-07-10 7:18 ` Georg Bauhaus @ 2008-07-10 14:37 ` Robert A Duff 2008-07-10 15:19 ` Adam Beneschan 1 sibling, 1 reply; 16+ messages in thread From: Robert A Duff @ 2008-07-10 14:37 UTC (permalink / raw) Dale Stanbrough <MrNoSpam@bigpoop.net.au> writes: > The purpose of an extended return is to create the values in-situ > without copying. No, that's not correct. Limited function results are built in place, nonlimited ones are not. It's got nothing to do with which sort of return statement you use -- limited builds in place even when you say "return <expression>;". The purpose of extended return is to give a name to the result, so you can poke at it, or assert things about it, etc. This capability is needed for limited types, but is also useful for nonlimited types. Your example below uses a nonlimited type, and it would be wrong for the compiler to use build-in-place in this case -- the left-hand side of an assignment must not be modified if the right-hand side raises an exception. An implementation can use build-in-place for nonlimited types, but only in cases where it can prove that there is no visible difference, such as when you are initializing a new object, or if there are no references to the object in any relevant exception handler. The example below is not such a case. I intend to make GNAT use build-in-place for nonlimited types in some cases someday, for efficiency. But it's low priority. - Bob > ------------------------------------------------- > with Ada.Text_IO; use Ada.Text_IO; > with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; > > procedure Returning_Large_Objects is > > type List is array (1..4) of Integer; > > > function Extended_Return_Error (Raise_Exception : Boolean) > return List > is > begin > return L : List do > L (1) := 1; L (2) := 2; > if Raise_Exception then raise Constraint_Error; end if; > L (3) := 3; L (4) := 4; > end return; > end; > > Destination : List; > > ------------------------------- > procedure Put (Item : List) is > begin > for i in Item'range loop > Put (Item (I)); > end loop; > New_Line; > end; > > begin > > -- run normally, no exception > > Destination := (others => 0); > > Put (Destination); > Destination := Extended_Return_Error (false); > Put (Destination); > > -- displays 1 2 3 4 as expected > > --------------------------------- > -- run with exception in middle > > Destination := (others => 0); > Put (Destination); > begin > Destination := Extended_Return_Error (true); > exception > when others => null; > end; > > Put (Destination); > -- displays 0 0 0 0, i expected 1 2 0 0 > > -- the exception seems to have affected statements > -- that precede it > > > end Returning_Large_Objects; > > -- > dstanbro@spam.o.matic.bigpond.net.au ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 14:37 ` Robert A Duff @ 2008-07-10 15:19 ` Adam Beneschan 2008-07-10 18:36 ` Dmitry A. Kazakov 2008-07-11 0:29 ` Robert A Duff 0 siblings, 2 replies; 16+ messages in thread From: Adam Beneschan @ 2008-07-10 15:19 UTC (permalink / raw) On Jul 10, 7:37 am, Robert A Duff <bobd...@shell01.TheWorld.com> wrote: > Dale Stanbrough <MrNoS...@bigpoop.net.au> writes: > > The purpose of an extended return is to create the values in-situ > > without copying. > > No, that's not correct. Limited function results are built in place, > nonlimited ones are not. It's got nothing to do with which sort of > return statement you use -- limited builds in place even when you > say "return <expression>;". Actually, the situation with limited types isn't totally clear, either. However, for limited types, there's no way Dale could test this using the sort of example he used above, since he used his Extended_Return_Function on the right-hand side of an assignment, which wouldn't be allowed for a function returning a limited type. If he tried to use the function call as an initializer for some object X, and the function raised an exception and left, there's no way X could be examined to determine whether some of the components of X were set. But in AI05-67, I did come up with an example where an extended return with a limited function result was left with a GOTO, and the function then did another extended return, and I had a question about whether the components set up by the first extended return (if not overwritten by the second) were required to show up in the result. Your answer, Bob, was "no", and I think that if AI05-67 is adopted, the answer will still be "no", because this AI says that the function result object does not "morph" into the created object until the return is completed. The upshot of this AI is, I think, that (1) the object being worked on for an extended return is *not* an "alias" for the object being created, even for a limited type, and (2) although limited types aren't supposed to be copied, this is true only in an Ada semantic sense, and implementations are allowed to do any block- copies they wish as long as they get the Ada semantics right. -- Adam ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 15:19 ` Adam Beneschan @ 2008-07-10 18:36 ` Dmitry A. Kazakov 2008-07-11 0:43 ` Robert A Duff 2008-07-11 0:29 ` Robert A Duff 1 sibling, 1 reply; 16+ messages in thread From: Dmitry A. Kazakov @ 2008-07-10 18:36 UTC (permalink / raw) On Thu, 10 Jul 2008 08:19:41 -0700 (PDT), Adam Beneschan wrote: > The upshot of this AI is, I think, that (1) the object > being worked on for an extended return is *not* an "alias" for the > object being created, even for a limited type, and (2) although > limited types aren't supposed to be copied, this is true only in an > Ada semantic sense, and implementations are allowed to do any block- > copies they wish as long as they get the Ada semantics right. Right, and the position 1 is inconsistent with the notion of limited type. A "backdoor" 2 does not save it as the following example illustrates: with Ada.Finalization; with Ada.Text_IO; use Ada.Text_IO; procedure Test_Return is package Test is type T is new Ada.Finalization.Limited_Controlled with null record; overriding procedure Finalize (X : in out T); overriding procedure Initialize (X : in out T); function Create return T; end Test; package body Test is procedure Finalize (X : in out T) is begin Put_Line ("Finalized"); end Finalize; procedure Initialize (X : in out T) is begin Put_Line ("Initialized"); end Initialize; function Create return T is begin return X : T do raise Constraint_Error; end return; exception when Constraint_Error => return X : T; end Create; end Test; use Test; X : T := Create; begin null; end Test_Return; The output should be: Initialized Finalized Initialized Finalized This is a case when *a* limited object is initialized and finalized twice, which is semantically inconsistent. OK, Initialize is not a constructor. But we could rewrite the above so that Create would call itself multiple times over the "same" X before it would finally "return" X! -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 18:36 ` Dmitry A. Kazakov @ 2008-07-11 0:43 ` Robert A Duff 2008-07-11 7:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 16+ messages in thread From: Robert A Duff @ 2008-07-11 0:43 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Thu, 10 Jul 2008 08:19:41 -0700 (PDT), Adam Beneschan wrote: > >> The upshot of this AI is, I think, that (1) the object >> being worked on for an extended return is *not* an "alias" for the >> object being created, even for a limited type, and (2) although >> limited types aren't supposed to be copied, this is true only in an >> Ada semantic sense, and implementations are allowed to do any block- >> copies they wish as long as they get the Ada semantics right. > > Right, and the position 1 is inconsistent with the notion of limited type. > A "backdoor" 2 does not save it as the following example illustrates: I don't see any problem here. The "notion of limited type" is "do not copy". In the example below, X is created, then destroyed, then another X is created, and that becomes the result. No copying. > with Ada.Finalization; > with Ada.Text_IO; use Ada.Text_IO; > > procedure Test_Return is > package Test is > type T is > new Ada.Finalization.Limited_Controlled with null record; > overriding > procedure Finalize (X : in out T); > overriding > procedure Initialize (X : in out T); > function Create return T; > end Test; > > package body Test is > procedure Finalize (X : in out T) is > begin > Put_Line ("Finalized"); > end Finalize; > procedure Initialize (X : in out T) is > begin > Put_Line ("Initialized"); > end Initialize; > function Create return T is > begin > return X : T do > raise Constraint_Error; > end return; > exception > when Constraint_Error => > return X : T; > end Create; > end Test; > > use Test; > X : T := Create; > begin > null; > end Test_Return; > > The output should be: > > Initialized > Finalized > Initialized > Finalized Right. > This is a case when *a* limited object is initialized and finalized twice, > which is semantically inconsistent. No, X is initialized and finalized, then a different X is initialized, which becomes a still-different X, which is then finalized. I don't see how that's "semantically inconsistent". > OK, Initialize is not a constructor. But we could rewrite the above so that > Create would call itself multiple times over the "same" X before it would > finally "return" X! - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-11 0:43 ` Robert A Duff @ 2008-07-11 7:39 ` Dmitry A. Kazakov 2008-07-11 9:06 ` christoph.grein 0 siblings, 1 reply; 16+ messages in thread From: Dmitry A. Kazakov @ 2008-07-11 7:39 UTC (permalink / raw) On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote: > I don't see any problem here. The "notion of limited type" is "do not > copy". In the example below, X is created, then destroyed, then another > X is created, and that becomes the result. No copying. No, we cannot say that, because A) X is not created until the constructing function returns. There is just no X until that point. The question is *what* was created and destroyed? It is improperly typed, at least. B) On the other hand, if we considered X being created, destroyed and created again, then the name X would resolve into two different objects in the same context. This would either violate the identity semantics of X or be semantically equivalent to an assignment of X. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-11 7:39 ` Dmitry A. Kazakov @ 2008-07-11 9:06 ` christoph.grein 2008-07-11 14:24 ` Dmitry A. Kazakov 0 siblings, 1 reply; 16+ messages in thread From: christoph.grein @ 2008-07-11 9:06 UTC (permalink / raw) On 11 Jul., 09:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote: > > I don't see any problem here. The "notion of limited type" is "do not > > copy". In the example below, X is created, then destroyed, then another > > X is created, and that becomes the result. No copying. > > No, we cannot say that, because > > A) X is not created until the constructing function returns. There is just > no X until that point. The question is *what* was created and destroyed? It > is improperly typed, at least. > > B) On the other hand, if we considered X being created, destroyed and > created again, then the name X would resolve into two different objects in > the same context. This would either violate the identity semantics of X or > be semantically equivalent to an assignment of X. I view it this way: There is a certain storage region where something (first X) is created and then distroyed. There is again a certain storage region (may be the same, may be not) where the second X is created. Only when the function returns becomes this storage region known a the final limited object. No copying. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-11 9:06 ` christoph.grein @ 2008-07-11 14:24 ` Dmitry A. Kazakov 0 siblings, 0 replies; 16+ messages in thread From: Dmitry A. Kazakov @ 2008-07-11 14:24 UTC (permalink / raw) On Fri, 11 Jul 2008 02:06:17 -0700 (PDT), christoph.grein@eurocopter.com wrote: > On 11 Jul., 09:39, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> > wrote: >> On Thu, 10 Jul 2008 20:43:09 -0400, Robert A Duff wrote: >>> I don't see any problem here. �The "notion of limited type" is "do not >>> copy". �In the example below, X is created, then destroyed, then another >>> X is created, and that becomes the result. �No copying. >> >> No, we cannot say that, because >> >> A) X is not created until the constructing function returns. There is just >> no X until that point. The question is *what* was created and destroyed? It >> is improperly typed, at least. >> >> B) On the other hand, if we considered X being created, destroyed and >> created again, then the name X would resolve into two different objects in >> the same context. This would either violate the identity semantics of X or >> be semantically equivalent to an assignment of X. > > I view it this way: > > There is a certain storage region where something (first X) is created > and then distroyed. But there cannot be first and second X, when X is limited! The object X is *one* object. It must be created strictly once. It can change its state, but it cannot disappear and reappear, that is not state change. So the question stands: what was created and then destroyed? The following question is: what is the type of that thing (which the type cannot be T.) > There is again a certain storage region (may be the same, may be not) > where the second X is created. Only when the function returns becomes > this storage region known a the final limited object. No copying. I don't think that limitmess is only about copying. It is rather about keeping the identity of the object. The latter implies the former but not necessarily reverse. When I see a sequence Initialize - Finalize - Initialize attributed to the same object, that is a sequence of assignment to me. The storage region used is in my view irrelevant here. I agree with Adam that "limitness" may allow moving bit patterns in the memory. It is OK, because the identity of a limited object is not necessarily the memory address, though an implementation may choose memory location for this purpose. So the issue boils down to the meaning of "in-place." -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Extended return question 2008-07-10 15:19 ` Adam Beneschan 2008-07-10 18:36 ` Dmitry A. Kazakov @ 2008-07-11 0:29 ` Robert A Duff 1 sibling, 0 replies; 16+ messages in thread From: Robert A Duff @ 2008-07-11 0:29 UTC (permalink / raw) Adam Beneschan <adam@irvine.com> writes: > On Jul 10, 7:37 am, Robert A Duff <bobd...@shell01.TheWorld.com> > wrote: >> Dale Stanbrough <MrNoS...@bigpoop.net.au> writes: >> > The purpose of an extended return is to create the values in-situ >> > without copying. >> >> No, that's not correct. Limited function results are built in place, >> nonlimited ones are not. It's got nothing to do with which sort of >> return statement you use -- limited builds in place even when you >> say "return <expression>;". > > Actually, the situation with limited types isn't totally clear, > either. It's pretty clear to me. ;-) I agree the RM wording is not crystal clear -- hence the AI you mention below. >...However, for limited types, there's no way Dale could test > this using the sort of example he used above, since he used his > Extended_Return_Function on the right-hand side of an assignment, > which wouldn't be allowed for a function returning a limited type. Right. But if we're being really precise, we need to use standard Ada terms. "Assignment" is (confusingly) not a shorthand for "assignment statement", in Ada. You mean "assignment statement" above. And when I said "limited" in my previous message, I really meant "immutably limited", as Randy pointed out. A limited private type whose full type is "range 1..10", or a generic formal limited private type whose actual is "range 1..10" doesn't count. We're talking about types that are really limited, "deep down". >...If > he tried to use the function call as an initializer for some object X, > and the function raised an exception and left, there's no way X could > be examined to determine whether some of the components of X were set. Right. That's one of the cases where the compiler can safely use build-in-place for nonlimited types. > But in AI05-67, I did come up with an example where an extended return > with a limited function result was left with a GOTO, and the function > then did another extended return, and I had a question about whether > the components set up by the first extended return (if not overwritten > by the second) were required to show up in the result. Your answer, > Bob, was "no",... Right. For inherently limited types, the return object, and the object being initialized are one and the same object. But the object being initialized doesn't exist until the return statement completes successfully -- if it is left via goto, exit, or (more likely) an exception, then a different return object may eventually be created, which will _be_ the object being initialized. >... and I think that if AI05-67 is adopted, the answer will > still be "no", because this AI says that the function result object > does not "morph" into the created object until the return is > completed. The upshot of this AI is, I think, that (1) the object > being worked on for an extended return is *not* an "alias" for the ^^^^^^^^^^^^^^^ Again, the return syntax is irrelevant! > object being created, even for a limited type,... For an immutably limited type, the return object is an alias for object that _will_ be created, if we get that far. >.. and (2) although > limited types aren't supposed to be copied, this is true only in an > Ada semantic sense, and implementations are allowed to do any block- > copies they wish as long as they get the Ada semantics right. Yes, of course -- if an implemention has garbage collection, it can copy anything it likes, including tasks, so long as it patches up all the pointers properly, so the copying is semantically invisible. E.g. if you have a record with a Self component that points to the record, it had better still point to itself after returning from the function. The easiest way to implement that is to make sure that the address of the return object is the same as the address of the newly-created object at the call site (which is exactly what GNAT does). - Bob ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2008-07-11 14:24 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-10 2:11 Extended return question Dale Stanbrough 2008-07-10 7:18 ` Georg Bauhaus 2008-07-10 7:32 ` Dale Stanbrough 2008-07-10 15:24 ` Adam Beneschan 2008-07-10 23:56 ` Dale Stanbrough 2008-07-10 23:20 ` Randy Brukardt 2008-07-11 0:03 ` Adam Beneschan 2008-07-11 0:50 ` Robert A Duff 2008-07-10 14:37 ` Robert A Duff 2008-07-10 15:19 ` Adam Beneschan 2008-07-10 18:36 ` Dmitry A. Kazakov 2008-07-11 0:43 ` Robert A Duff 2008-07-11 7:39 ` Dmitry A. Kazakov 2008-07-11 9:06 ` christoph.grein 2008-07-11 14:24 ` Dmitry A. Kazakov 2008-07-11 0:29 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox