Initialise string function result?

Question

I\'ve just been debugging a problem with a function that returns a string that has got me worried. I\'ve always assumed that the implicit Result variable for functions that

Answer 1

Alex's answer is nearly always right and it answers why I was seeing the strange behaviour that I was, but it isn't the whole story.

The following, compiled without optimisation, produces the expected result of sTemp being an empty string. If you swap the function out for the procedure call you get a different result.

There seems to be a different rule for the actual program unit.

Admittedly this is a corner case.

program Project1;

{$APPTYPE CONSOLE}

uses System.SysUtils;

  function PointlessFunction: string;
  begin
  end;

  procedure PointlessProcedure(var AString: string);
  begin
  end;

var
  sTemp: string;
begin
  sTemp := '1234';
  sTemp := PointlessFunction;
  //PointlessProcedure(sTemp);
  WriteLn('Result:' + sTemp);
  ReadLn;
end.

Answer 2

This is not a bug, but "feature":

For a string, dynamic array, method pointer, or variant result, the effects are the same as if the function result were declared as an additional var parameter following the declared parameters. In other words, the caller passes an additional 32-bit pointer that points to a variable in which to return the function result.

I.e. your

function TMyObject.GenerateInfo: string;

Is really this:

procedure TMyObject.GenerateInfo(var Result: string);

Note "var" prefix (not "out" as you may expect!).

This is SUCH un-intuitive, so it leads to all kind of problems in the code. Code in question - just one example of results of this feature.

See and vote for this request.

Answer 3

It seems like your function should be simplified like this:

function TMyObject.GenerateInfo: string;
begin
  if(ACondition) then
    Result := 'Some Text'
  else
    Result := '';
end;

You typically don't want to use Result on the right side of an assignment in a function.

Anyway, strictly for illustrative purposes, you could also do this, though not recommended:

procedure TForm1.Button1Click(Sender: TObject);
var
  i: integer;
  S: string;
begin
  for i := 1 to 5 do
  begin
    S := ''; // Clear before you call
    S := GenerateInfo;
  end;
  ShowMessage(S); // 5 lines!
end;

Answer 4

This looks like a bug in D2007. I just tested it in Delphi 2010 and got the expected behavior. (1 line instead of 5.)

Answer 5

This is not a Bug. By definition no variable inside function is initialized, including Result.

So your Result is undefind on first call, and can hold anything. How it is implemented in compiler is irrelevant, and you can have different results in different compilers.

Answer 6

If you think that some automatic management of strings are made to make your life easier, you're only partly right. All such things are also done to make string logic consistent and side-effects free.

In plenty of places there are string passed by reference, passed by value, but all these lines are expecting VALID strings in whose memory-management counter is some valid, not a garbage value. So in order to keep strings valid the only thing for sure is that they should be initialized when they firstly introduced. For example, for any local variable string this is a necessity since this is the place a string is introduced. All other string usage including function(): string (that actually procedure(var Result: string) as Alexander correctly pointed out) just expects valid strings on the stack, not initialized. And validness here comes from the fact that (var Result: string) construction says that "I'm waiting for a valid variable that definetly was introduced before". UPDATE: Because of that the actual contents of Result is unexpected, but due to the same logic, if it's the only call to this function that has a local variable at the left, the emptiness of the string in this case is guaranteed.