experchange > delphi

Oliver Bleckmann (12-20-05, 08:15 PM)
Hi,
my brother asked me about this, now I ask you.
This should work for FreePascal, but not for Borland Pascal 6.0 or 7.0 -
WHY?
Any suggestions or workarounds?

Error in TP 7: Invalif function result type (see <--)

type
feld = (leer, NF, TF, SK, TP, A); {FELDART}
aufbau = record {EIGENSCHAFTEN DER SPIELFELDER}
art : feld; {FELDART}
entdeckt : boolean; {TRUE WENN VOM USER FELD BETRITT}
end;
laby = array [1..lab_xSize, 1..lab_ySize] of aufbau;
{LABYRINTHAUFBAU}

function createlab(var aus_x, aus_y : integer) : laby; <--
.......
Bruce Roberts (12-20-05, 09:42 PM)
"Oliver Bleckmann" <Oliver-Bleckmann> wrote in message
news:ko61
> Hi,
> my brother asked me about this, now I ask you.
> This should work for FreePascal, but not for Borland Pascal 6.0 or 7.0 -
> WHY?


IIRC BP function results were either passed back in registers, an fpu
register, or as a double word stack entry (in the case of strings). While I
haven't found an explicit explanation, I would expect that neither records
or array types could be used as function result types. I wouldn't be
surprised if sets, at least those with a base type of cardinality > 32,
were also disallowed.

> Any suggestions or workarounds?


Add a Var parameter of the appropriate type and turn the function into a
procedure. Or, as another poster suggested return a pointer type.
Marco van de Voort (12-20-05, 10:21 PM)
On 2005-12-20, Bruce Roberts <dontsendtober> wrote:
> "Oliver Bleckmann" <Oliver-Bleckmann> wrote in message
> news:ko61
> IIRC BP function results were either passed back in registers, an fpu
> register, or as a double word stack entry (in the case of strings). While I
> haven't found an explicit explanation, I would expect that neither records
> or array types could be used as function result types. I wouldn't be
> surprised if sets, at least those with a base type of cardinality > 32,
> were also disallowed.


>16, since BP is a 16-bit compiler.


Another possibility is that the dimensions of the array are larger than 64k.
Maarten Wiltink (12-20-05, 10:44 PM)
"Oliver Bleckmann" <Oliver-Bleckmann> wrote in message
news:ko61

> my brother asked me about this, now I ask you.
> This should work for FreePascal, but not for Borland Pascal 6.0 or
> 7.0 - WHY?


> type laby = array [1..lab_xSize, 1..lab_ySize] of aufbau;
> function createlab(var aus_x, aus_y : integer) : laby; <--


As originally designed, Pascal only allowed functions to return
values that could fit in a register. Integers, pointers, but not
records or arrays. This rule was later relaxed by individual
compilers that returned values on the stack if necessary.

Pascal is riddled with such premature optimisation. Most of it
is firmly obsolete.

Groetjes,
Maarten Wiltink
Jamie (12-20-05, 11:49 PM)
Oliver Bleckmann wrote:
[..]
Bruce Roberts (12-21-05, 02:05 AM)
"Maarten Wiltink" <maarten> wrote in message
news:514c

> As originally designed, Pascal only allowed functions to return
> values that could fit in a register. Integers, pointers, but not
> records or arrays. This rule was later relaxed by individual
> compilers that returned values on the stack if necessary.


I hadn't realized that it was a Pascal limitation. On reading your post I
dug out my Pascal User Manual and Report. Sure enough, on page 78 of the
User Manual it says "The result type must be a scalar, subrange, or pointer
type."

> Pascal is riddled with such premature optimisation. Most of it
> is firmly obsolete.


Very true.
Marco van de Voort (12-21-05, 09:50 AM)
On 2005-12-20, Maarten Wiltink <maarten> wrote:
> As originally designed, Pascal only allowed functions to return
> values that could fit in a register. Integers, pointers, but not
> records or arrays. This rule was later relaxed by individual
> compilers that returned values on the stack if necessary.
> Pascal is riddled with such premature optimisation. Most of it
> is firmly obsolete.


In this case I think it is correct, since laby is a fairly large creature.
Hanford Carr (12-21-05, 04:55 PM)
Oliver Bleckmann wrote:
[..]
> {LABYRINTHAUFBAU}
> function createlab(var aus_x, aus_y : integer) : laby; <--
> ......


From BP 70 help:
"A function is a program part that computes and returns a
value.
....
Valid result types are ordinal, real, string, and pointer. ..."

Hanford
Femme Verbeek (12-22-05, 04:11 AM)
Bruce Roberts schreef:
> "Oliver Bleckmann" <Oliver-Bleckmann> wrote in message
> news:ko61
> IIRC BP function results were either passed back in registers, an fpu
> register, or as a double word stack entry (in the case of strings). While I
> haven't found an explicit explanation, I would expect that neither records
> or array types could be used as function result types.


Correct.

>I wouldn't be
> surprised if sets, at least those with a base type of cardinality > 32,
> were also disallowed.

sets in BP/TP are restricted to 256 entries so it can be stored in one
byte.
Bruce Roberts (12-22-05, 05:34 PM)
"Femme Verbeek" <fv> wrote in message
news:khr1

> sets in BP/TP are restricted to 256 entries so it can be stored in one
> byte.


Set cardinality up to 256 means up to 32 bytes (256 bits / 8).
Hans-Peter Diettrich (12-22-05, 09:45 PM)
Femme Verbeek schrieb:

> sets in BP/TP are restricted to 256 entries so it can be stored in one
> byte.


You confuse enums and sets. An enum with up to 256 elements requires a
byte of storage (256 distinct states), but an set of 256 elements
requires 256 bits.

DoDi
Similar Threads