Hi,

I tried to write some function that returned a dynamic array, and realized that this isn't allowed. Why? After all one can specify an array of variable length as type for variables... Furthermore - if I'm not mistaken - a dynamic array is implemented internally as a pointer, and so there wouldn't be any runtime overhead for returning a dynamic array from a function.

Thanks,

Christos Chryssochoidis

It *is* allowed. The only trick is that you have to declare a type for your dynamic array, i.e. you have to write something like

  type TDynInts = array of Integer;
  function MakeArray: TDynInts;

instead of

  function MakeArray: array of Integer;

This quick example compiles fine in objfpc mode:

type
  TDynInts = array of Integer;
function MakeArray: TDynInts;
begin
  SetLength(Result, 2);
  Result[0] := 0;
  Result[1] := 1;
end;
var
  A: TDynInts;
begin
  A := MakeArray;
  Writeln(A[0], ' ', A[1]);
end.

Michalis

Op Wed, 23 May 2007, schreef Michalis Kamburelis:

I think this is one more example open array versus dynamic array confusion. Arrays declared in type statements are dynamic arrays; arrays declared in procedure/function headers are open arrays. You can return a dynamic array, but not an open array.

Daniël

Yes, I have noticed that if you first wrap a dynamic array in a type definition then you can declare a function returning such an array, but it seemed to me as an unnecessary complication of things and as an inconsistency in the language. However, the distinction between dynamic and open arrays that D.Mantione says, explains this complication.

Thanks very much for your answers,

Christos

It is not a trick, but has to do with type compatibility issues (and history, I guess).

If you have

function f(...): SomeType;

then the result of calling f needs to go somewhere. Either it "disappears" as an intermediate result in a larger expression, or you assign it to a variable (or such). In case it is a subexpression, the result of f acts as a parameter of an enclosing function or operator.

while f(...) operator ... do ...

if g( f(...) ) then ...

  v := f(...)

The receiving parameter or variable needs to have a type "compatible" with SomeType. If SomeType is a type expression, then you cannot declare a parameter or variable of the same type by copying the type expression. In Pascal,

var
  a: array [ Char ] of Integer;
  b: array [ Char ] of Integer;
function g(p: array [ Char ] of Integer);
function f(c: Char; i: Integer): array [ Char ] of Integer;

does not (automatically) make a and b have the same type (in some cases automatic conversions etc. will give you some kind of compatibility).

For that (partly historic) reason, parameter types and return types must be type names and not type expressions.

Of course, there situations where you can argue that it works without using type names. E.g. if you return a record type, one way of using it would be to select a field:

function f(...): record x, y: Integer end;
  if f(...).x = 0 then ...

The "operation" of field selection works on arbitrary record types. Insisting on a type name seems unneeded. I.e. the typing of the "parameters" of . is not so strict; it occurs in a context

record . fieldname_of_this_record_type

The record is not a parameter of . in the usual sense.

I haven't checked the FPC documentation on all this.

Tom

I see. If I understand well, Pascal uses some sort of declaration equivalence for types.

Christos

Correct. In general, it is costly (or even hard/impossible) for a compiler to determine equivalence of type _expressions_.

Variables and parameters declared with the same type _name_ are (obviously) of the same type.

Tom