[SOLVED] functions with same return record-type share a record(?)

[MMarie]

After working on a project this evening I've realised that i'm relying on the fact that multiple of my functions which call into oneanother share the same record as a result?

e.g.

Code: Pascal  [Select][+][-]

1. type
2.   TFoo = record
3.     {...}
4.     bar: String;
5.   end;
6.  
7. function A: TFoo;
8. begin
9.   A.bar := A.bar + ' bar';
10. end;
11.  
12. function B: TFoo;
13. begin
14.   B.bar := 'foo'
15.   B := A;
16.   writeln(B.bar);
17. end;
18.  

when calling B, it would output "foo bar". My question here is: is this intended behaviour, on which I can rely? Are there any caveats when relying on this?

[Fibonacci]

That is an invalid memory access. You must initialize the record with default values or simply call FillChar(result, SizeOf(result), 0), or there will be garbage in the returned record, you absolutely cannot rely on this behavior.

[Thaddy]

Indeed, that gives unpredicable behavior. Better is:

Code: Pascal  [Select][+][-]

1. type
2.   TFoo = record
3.     {...}
4.     bar: String;
5.   end;
6.  
7. function A: TFoo;
8. begin
9.   A:=Default(TFoo);
10.   A.bar := A.bar + ' bar';
11. end;
12.  
13. function B: TFoo;
14. begin
15.   B:=Default(TFoo);
16.   B.bar := 'foo'
17.   B := A;
18.   writeln(B.bar);
19. end;

More in general you can also use a management operator to make sure a record is always properly initialized. And you can use "Result" to distinguish between function result and the function itself. Your syntax is a bit old school, but valid pascal.
 

[Thaddy]

Here's a more modern approach, but note your code is valid and basically this is just about notational differences that can improve readability:

Code: Pascal  [Select][+][-]

1. {$mode objfpc}{$modeswitch advancedrecords}
2. type
3.   TFoo = record
4.     bar: String;
5.     class operator Initialize(var Value:TFoo);
6.   end;
7.  
8. { called automatically, once per instance }
9. class operator TFoo.Initialize(var Value:TFoo);
10. begin
11.    value := Default(TFoo);
12. end;
13.  
14. function A: TFoo;
15. begin
16.   Result.bar := Result.bar + ' bar';
17. end;
18.  
19. function B: TFoo;
20. begin
21.   Result := A;
22. end;
23.  
24. begin
25.   writeln(a.bar);
26.   writeln(b.bar);
27.   writeln(a.bar);
28.   writeln(b.bar);
29.   writeln(a.bar);
30.   writeln(b.bar);
31. end.

You can ignore the compiler warnings, because the record is always initialized, stack or heap allocated.
You can also see that there is no record sharing, but record copying.

[dbannon]

Yes, the OP's code was definitely wrong. But I am intensely puzzled as to how it worked ?  I just tried it, and, again, it works.

In function A, the result.bar contains 'foo', at the start of the function, the only way it can get that information is from functions B's result.bar. Just looking at the code, I would have said function A's result.bar is just as likely to contain the Complete Works of Shakespeare as "foo".

Until the assignment happens at the end of function A, there is no connection between the two result variables. Is there ?

Davo

EDIT: No, I see, a function uses the variable its going to write to as its result variable. Wow, I did not realise that .....

[Thaddy]

It is not that strange that it works, because the record is allocated on the heap. Problems only arise if allocated on the stack.

[Thaddy]

Yes, the OP's code was definitely wrong.

The original code is NOT wrong, Davo, but it does not represent his intention:
Without initialization, it only goes wrong when called from inside of a procedure or function.
Otherwise it is heap memory and heap memory is initialized.
This archaic old man can still read archaic syntax.
Problems only occur when you nest those calls inside a method, procedure or function, because that is stack memory and stack memory is undetermined.
And before you start complaining, result variables have of course outer scope, not inner scope. Think.

[simone]

Just out of curiosity: is the new feature of record management operators documented in the language reference guide?

I only found this wiki: https://wiki.freepascal.org/management_operators

Thanks.

[Thaddy]

Yes. It is.

[alpine]

It is not that strange that it works, because the record is allocated on the heap. Problems only arise if allocated on the stack.

IMO the heap is not involved at all. The OP example works because it has just one field and,  by coincidence, A reuses result variable of B as its own result. In other scenarios it just may not work properly.

[MarkMLl]

IMO the heap is not involved at all. The OP example works because it has just one field and,  by coincidence, A reuses result variable of B as its own result. In other scenarios it just may not work properly.

I admit to not understanding why those functions aren't going recursive.

MarkMLl

[simone]

Yes. It is.

I'm sorry, but I don't think so. Just as the free standing (i.e. outside the classes) generic procedures / functions and other more recent features are not documented in the language reference guide. If I'm wrong, I apologize and ask you in which section of the guide they are described.

[alpine]

I admit to not understanding why those functions aren't going recursive.

Also a good point.

Isn't it that the Result variable was introduced to solve?

[jamie]

That looks perfectly valid code.

A needs a return record so it's using B, and since B gets defined beforehand, it already has the initial value.

[Fibonacci]

That looks perfectly valid code.

A needs a return record so it's using B, and since B gets defined beforehand, it already has the initial value.

Nah. Its invalid, its unpredictable. OPs code prints "foo bar", but with this line 16 below that does nothing it prints " bar".

Code: Pascal  [Select][+][-]

1. type
2.   TFoo = record
3.     bar: String;
4.   end;
5.  
6. function A: TFoo;
7. begin
8.   A.bar := A.bar + ' bar';
9. end;
10.  
11. function B: TFoo;
12. begin
13.   B.bar := 'foo';
14.   B := A;
15.   writeln(B.bar);
16.   if dword(@B) <> 0 then;
17. end;
18.  
19. begin
20.   b;
21.   readln;
22. end.