Initialization and Finalization of limited object "returned" by a function
in [ADA]
|
Prev: Tiny mistaken on an AdaPower page
Next: Initialization and Finalization of limited object "returned"by a function
From: Hibou57 (Yannick Duchêne) on 11 Feb 2010 17:49 On 11 fév, 22:51, Adam Beneschan <a...(a)irvine.com> wrote: > For an extended return, > > return R : T; > > R is not a local variable, and it isn't "assigned" into the anonymous > object; thus, there's no Adjust, and R is not finalized when the > function returns Yes > (but the anonymous object will be finalized later, Which anonymous object ? > except when it mutates into some other object). Ouch, requires clarifications (at least to me) > I think that's the > point of the nasty language in 3.10.2(10.1). Do you suggest the behavior I'm experiencing is the expected one ? (being nasty or not) > Which is another way of > saying that R is a name for the result (as you said), What I was expecting, indeed > not a distinct > object that gets copied to the result. I hope so : it's limited ! > I thought it would be helpful > to point it out---not to you, but to other readers. It's hardly a > trivial difference, and it's an important one to understand when > adjusts and finalizations are involved. Anyway, I hope this helps > someone. Probably I'm one of the "other readers" Well, I will later drive another experiment, a shorter one, as Robert/ Bob suggested the example source I gave was a bit too long to be quickly studied.
From: Hibou57 (Yannick Duchêne) on 11 Feb 2010 17:53 Clarification about my words : what I've quoted from you, was talking about extended return statement. I was understanding this as "extended return statement applied to limited". If this was ever not what you were talking about, there are chance I've understood what you were to say. I will look again at the ARM reference you've pointed (as well as the ones suggested in your previous post in this same thread).
From: Hibou57 (Yannick Duchêne) on 11 Feb 2010 18:15 On 11 fév, 12:00, Ludovic Brenta <ludo...(a)ludovic-brenta.org> wrote: > Yannick Duchêne wrote on comp.lang.ada: > > > Tested_Interface : Dispatch.Instance_Class := > > (Dispatch.New_Instance); > > Here you are initializing with an aggregate that contains the result > of the function call. I suspect this triggers a compiler bug. What > happens if you remove the parentheses? As Jean-Pierre explained, this is not an aggregate, its a parenthesized expression. Let me explain why such a simple expression is parenthesized here : this is just a matter of text layout. I follow one part of the convention which is in use in the world of GNAT/GPS, which applies an outdent of one character whenever a language construct which is able to start with a parenthesis span multiple lines. This make sens for a complex expression or an enumeration spanning multiple lines as an example (in the latter example, the first parenthesis being outdent of one character, the first item which comes next to it, has thus the same indent as all the following items). But as this outdent is always to be there, if the construct is not parenthesized, then the indentation is not the expected one. So, when it happens a simple expression has to stand to the next line, indented, just because it would have otherwise go beyond the line width limit (which is 67 characters when I post example source on c.l.a), it turns to be a simple expression with parenthesis. That's true that a lot of parenthesized constructs of the Ada language may seems ambiguous at first sight. But these potential ambiguities are gracefully handled by some language rules intended for adjustment and ambiguity removal, so that it is finally not ambiguous at all.
From: Hibou57 (Yannick Duchêne) on 11 Feb 2010 18:18 On 12 fév, 00:08, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > Extended return statements are not much more than syntactic sugar. On my way, I feel it's not so much syntactic sugar and it's mostly required. Otherwise, a local variable would have to be used, which would look like a return by copy. By the way, that's true I have make use of extended return where simple return statement would have been sufficient. I'm back to the remaining of your post now.
From: Adam Beneschan on 11 Feb 2010 18:41
On Feb 11, 2:53 pm, Robert A Duff <bobd...(a)shell01.TheWorld.com> wrote: > It doesn't matter whether the result object has a name or not. > What matters is whether it's limited -- in the limited case, > the result object is NOT finalized when leaving the function. But that's true even if it's nonlimited, right? If NLT is non- limited, and you say (inside function NLT_Func) return X : NLT do X.Component := ... end return; X, which is now another name for the "anonymous result object" created for the function call, is not finalized "when leaving the function". It's finalized later. If you say Y : NLT := NLT_Func(...); it's finalized after being copied to Y (assuming it is not built in place). If you pass the result to some other function(s): Z : Type2 := Func2 (Func3 (NLT_Func (...))); then I believe the result object (of NLT_Func) is not finalized until after the entire expression is evaluated, right? -- Adam |