Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Passing record types as parameters.

1,578 views
Skip to first unread message

Philip Cain

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

I use several record type variables in my code. Usually, they are
local to a procedure and passed to other routines as parms of the
function or procedure call.

Normally this works well, but I have a problem when I call a routine
that wants a record as a parameter and no record is needed in this
particular instance.

If the parameter were an object, I could pass nil to the called
routine and everything would be ok. But records can't be nil.

I can't set up a dummy record either, because each record is a
different type and Delphi correctly complains that my dummy record is
the wrong type.

I've tried fooling around with pointers and typecasting, but I can't
seem to get it right.

Is there some generic way to refer to a record in a procedure
declaration so that any record can be passed or is this too
old-fashioned or beyond the design scope of Delphi?

TIA

Phil Cain

Roman Krejci

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Hi Philip,
you almost got it.
Instead of (VAR record: tRecord), pass just address of the record and
typecast the
pointer inside the called routine-this way you can pass NILs to them:

procedure blah1(recadr: pointer);
begin
if recadr<>NIL then tMyRec(recAdr^).fld :=....
end;

Var rec: tMyRec;
begin
blah1(@rec);
blah1(nil);

--
Roman
IN...@rksolution.cz (please remove STOPSPAM. in header)
Delphi corner now open at my website http://www.rksolution.cz

Philip Cain wrote in message <358babc4...@forums.borland.com>...

Philip Cain

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

"Roman Krejci" <STOPSPA...@MBOX.CESNET.CZ> wrote:

> if recadr<>NIL then tMyRec(recAdr^).fld :=....


You know, it was that little ^ do-hicky. I can't quite grasp their
use. I understand it in declarations (e.g. Pvar : ^Myvar) but in this
case, I miss the sense of where to put it (e.g. before the parens or
after it or before or after the period). One day I'll do a vision
quest and find the understanding.

Thanks for your help.

Phil

Ran

unread,
Jun 19, 1998, 3:00:00 AM6/19/98
to

Philip Cain wrote in message <358babc4...@forums.borland.com>...
>
>I use several record type variables in my code. Usually, they are
>local to a procedure and passed to other routines as parms of the
>function or procedure call.
>
>Normally this works well, but I have a problem when I call a routine
>that wants a record as a parameter and no record is needed in this
>particular instance.
>
>If the parameter were an object, I could pass nil to the called
>routine and everything would be ok. But records can't be nil.


Well, why not use an object? With the exception of the records needed by
Windows, I never create records since they are not very object-oriented.
Good encapsulation requires that there be no public variables, only getter
and setter methods or properties to private variables. Your do have the
overhead of creating and freeing the objects but the flexibility is well
worth it.


>I can't set up a dummy record either, because each record is a
>different type and Delphi correctly complains that my dummy record is
>the wrong type.


Using objects instead of records would allow the procedure to accept an
abstract class, which would be subclassed to you record class and your dummy
record class.


>I've tried fooling around with pointers and typecasting, but I can't
>seem to get it right.
>
>Is there some generic way to refer to a record in a procedure
>declaration so that any record can be passed or is this too
>old-fashioned or beyond the design scope of Delphi?


Even if it can be done, it is not object-oriented and you may be setting
yourself up for a serious bug in the future!


>TIA
>
>Phil Cain


Randall L. Pleasant
Dallas, Texas


Roman Krejci

unread,
Jun 20, 1998, 3:00:00 AM6/20/98
to

Hi Philip,
there's nothing mysterious in pointers.
Think of them simply as of 32bit addresses -
identification of the place in the memory where
the information is strored.
Dereferencing pointer "p^" then refers to the
actual _content_ of that piece of memory.
Typecasting the dereferenced pointer "tMyrec(p^)"
simply allows you to use that piece of memory as
if it was a record of type tMyRec.
Putting ^ after parens "tMyRec(p)^" would mean that
the pointer variable (address) should be looked at as if it was
of type tMyRec, which is obviously wrong (and the compiler
would not let you do that, anyway)
Wish you luck.
--
Roman

Philip Cain wrote in message <358cc4b2...@forums.borland.com>...

0 new messages