Board index » delphi » forward object in standard turbo pascal

forward object in standard turbo pascal

Hi,

In trying to encapsulate some C++ classes I've written and placed in a
DLL in Pascal objects, I've run into the problem that I cannot,
apparently, resolve references for forward objects. :-( I searched the
net and found some examples stating that this could be done by
myforward = CLASS; but this is Delphi extensions, and I need to do it
in "pure" turbo pascal. Is there a way to do that? Much obliged...

   These were the incoherent ramblings of ...
      ... /\/\\ads Orbesen Troest <mot...@RemoveThis.sprog.auc.dk>

 

Re:forward object in standard turbo pascal


Quote
Mads Orbesen Troest wrote in message ...
>...
> In trying to encapsulate some C++ classes I've written and placed in
a
> DLL in Pascal objects, I've run into the problem that I cannot,
> apparently, resolve references for forward objects. :-( I searched
the
> net and found some examples stating that this could be done by
> myforward = CLASS; but this is Delphi extensions, and I need to do
it
> in "pure" turbo pascal. Is there a way to do that? Much obliged...

The thing to remember is that, when forward referencing like that, a
compiler has to know how much space to reserve. Other stuff can be
worked out later, but you can't, for example, have a record with a
tWidget data member if the compiler doesn't know how many bytes are in
a tWidget - the other data members would get upset if the compiler
guesses wrong. But it knows how many bytes a _pointer_ to tWidget will
take, because pointers are all the same size. C++ will allow you to
forward reference a class, but AFAIK you cannot embed an instance of
that class in another definition - only a pointer to the class. In
Delphi the same applies only more so - because _all_ class instances
are on the heap and a class reference is a pointer pretending to be a
variable. So: because the compiler knows how big a pointer to a class
is, it can use a pointer to a class even if the class has not yet been
defined.

In pre-Delphi Pascal the same thing applies except that forward
referencing is more restrictive in that the pointer has to be declared
in the same block as the definition of what it points to. I think this
sort of forward declaration was introduced in the original Pascal to
allow linked lists and the like. (And it's in "Pure Turbo Pascal" as
well. "Pure Turbo Pascal"? Is that not a bit of an oxymoron, like
"Airline Food" or "Temporary tax increase"?) But it also applies to
objects. So you can do something like:

Type
  pt1 = ^t1;
  t2 = Object
    p : pt1;
  End;
  t1 = Object(t2)
  End;

where t2 has a pointer to a t1 object in it and t1 has a reference to
t2 (by being descended from it; more typically it might have t2 as a
data member or have methods that take parameters of type t2). This
compiles. But if you break the block up, by putting Type before "t1
=..." you get Error 19: Undefined type in pointer definition (t1) as
soon as "Type" is hit.

This seems very restrictive. However, since all method definitions are
separate from the object declarations, the declarations of all object
types could come before the start of any method code, so within the
body of the methods you should be able to access all of both objects,
if necessary.

As a last resort, you could declare a type from which the late class
is descended, and instead of using a forward reference to the
undeclared object, use a pointer to the ancestor type instead. And
make sure all its methods are virtual.

FP

Re:forward object in standard turbo pascal


Quote
On Mon, 27 Jul 1998 12:42:42, "Frank Peelo" <fpe...@indigo.ie> wrote:
> As a last resort, you could declare a type from which the late class
> is descended, and instead of using a forward reference to the
> undeclared object, use a pointer to the ancestor type instead. And
> make sure all its methods are virtual.

Thanks for your informative letter; I opted for using the Delphi-style
"class" extension to the "basic" Pascal "object" construct (which has
a means of defining forward references), as it turned out my (OS/2)
compiler had no problems with Delphi code.

   These were the incoherent ramblings of ...
      ... /\/\\ads Orbesen Troest <mot...@RemoveThis.sprog.auc.dk>

Other Threads