Board index » delphi » Compiler thinks Class = Record!

Compiler thinks Class = Record!

I have a class in unit A that is being created and referenced in unit
B.

When I try to compile it kicks back error 44: Field Identifier
Expected.

To me this looks like it think my class reference variable is a record
type of some sort.

Why?  Here is the pertinent info from Unit A, which describes the
class TMapDude:
----------------------------------------------------------
unit Mapdude;

interface

Uses
  Graphics;

Type

  {Forward declarations}
  TMapPtr = ^TMap;
  TMap = record;

  TMapDude = class
  private
    {List roots}
    ooMap: TMapPtr;
    ooPlayerList: TPlayersListPtr;
    ooTerrainList: TTerrainsListPtr;
    ooFeatureList: TFeaturesListPtr;

.
.
.
  public
    procedure DoNothing;

  end;

var
  oMapDude: TMapDude;

----------------------------------------------------------

And here is the code segment in Unit B that references MapDude:

   oMapDude := TMapDude.create;
   oMapDude.DoNothing();

Anyone have a clue?  I'm tired of sitting here like an idiot trying to
figure out what's wrong.

The weird part of the whole thing is that there are 4 other Unit files
in this project that are homegrown classes and they are being created
and referenced the same way as the example above, yet the compiled
does not care about them.

 

Re:Compiler thinks Class = Record!


gi...@clark.net (Edward G. Mittelstedt II) wrote:

Quote
>I have a class in unit A that is being created and referenced in unit
>B.
>When I try to compile it kicks back error 44: Field Identifier
>Expected.
>To me this looks like it think my class reference variable is a record
>type of some sort.
>Why?  Here is the pertinent info from Unit A, which describes the
>class TMapDude:
>----------------------------------------------------------
>unit Mapdude;
>interface
>Uses
>  Graphics;
>Type
>  {Forward declarations}
>  TMapPtr = ^TMap;
>  TMap = record;
>  TMapDude = class
>  private
>    {List roots}
>    ooMap: TMapPtr;
>    ooPlayerList: TPlayersListPtr;
>    ooTerrainList: TTerrainsListPtr;
>    ooFeatureList: TFeaturesListPtr;
>.
>.
>.
>  public
>    procedure DoNothing;
>  end;
>var
>  oMapDude: TMapDude;
>----------------------------------------------------------
>And here is the code segment in Unit B that references MapDude:
>   oMapDude := TMapDude.create;
>   oMapDude.DoNothing();
>Anyone have a clue?  I'm tired of sitting here like an idiot trying to
>figure out what's wrong.

Yep. It seems that like me, you've done plenty of programming in
Modula-2. The problem is the open and close parentheses "()" at the
end of the function call. Just get rid of them. If the function
doesn't need any parameters, you don't need the brackets. This might
seem a little silly when you start using procedures as pointers, but
the compiler resolves the conflict by checking the type info.

Martin H.
***********************************************
Martin Harvey
Uni email:
6D 63 68 32 34 40 63 61 6D 2E 61 63 2E 75 6B
Home email:
6D 63 68 32 34 40 68 61 72 76 65 79 32 37 2E 64
65 6D 6F 6E 2E 63 6F 2E 75 6B
Decode the HEX back into ASCII chars.
Uni web pages: http://www-stu.pem.cam.ac.uk/~mch24/
***********************************************

Re:Compiler thinks Class = Record!


Edward G. Mittelstedt II <gi...@clark.net> wrote in article
<5p6m58$...@clarknet.clark.net>...

Quote
>    oMapDude.DoNothing();

My guess is: you don't need the (). Write the
stmt as
 oMapDude.DoNothing;
but note I have simply I-bald your code, not compiled it.
--
Grace + Peace   *   Peter N Roth  *   Engineering Objects International
Author of "C++ Jump Start" ISBN 0-9655862-2-7.
Tools for Developers: ClassBuilder 4 for Delphi, ClassBuilder++ for C++
Visit our website at http://www.inconresearch.com/eoi

Re:Compiler thinks Class = Record!


Oops, disregard my last message on this subject.  I just took a closer look
at your code, and think I see your problem.  As defined, your class
inherits from TObject (by default).  Well, TObject does not define a Create
constructor, it is up to you to do this, and in the code given you have
not.  Therefore, the compiler rightly complains about not being able to
find the constructor.  The message is a bit misleading, but basically it is
saying that you have put xxx.yyy where yyy does not exist as a member of
class xxx...
--
David S. Becker
ADP Dealer Services (Plaza R&D)
d...@plaza.ds.adp.com
(503)402-3236
 Edward G. Mittelstedt II wrote in article <5p6m58$...@clarknet.clark.net>..
.

Quote
>I have a class in unit A that is being created and referenced in unit
>B.

>When I try to compile it kicks back error 44: Field Identifier
>Expected.

[snip]

Re:Compiler thinks Class = Record!


"David S. Becker" <d...@plaza.ds.adp.com> wrote:

Quote
>Oops, disregard my last message on this subject.  I just took a closer look
>at your code, and think I see your problem.  As defined, your class
>inherits from TObject (by default).  Well, TObject does not define a Create
>constructor, it is up to you to do this, and in the code given you have
>not.  Therefore, the compiler rightly complains about not being able to
>find the constructor.

Sorry, but you are mistaken.  TObject DOES define a default Create
constructor, which does nothing; that happens to be an adequate
functionality for many classes.  Check source\rtl\sys\SYSTEM.PAS.  There
are several examples of classes in the VCL which derive directly from
TObject and do not define their own Create.  TList is one example.

- Tim Roberts, t...@probo.com
  Providenza & Boekelheide, Inc.

Re:Compiler thinks Class = Record!


Quote
Tim Roberts wrote:
> [...]

> Sorry, but you are mistaken.  TObject DOES define a default Create
> constructor, which does nothing; that happens to be an adequate
> functionality for many classes.  Check source\rtl\sys\SYSTEM.PAS.  There
> are several examples of classes in the VCL which derive directly from
> TObject and do not define their own Create.  TList is one example.

        Surely TObject.Create does more than nothing, like for example
it allocates space for the object's fields? If I say

var O: TObject;
begin
end;

and the optimizer's having a bad day that object should take 4 bytes,
while if I say

var O: TObject;
begin
O:= TObject.Create;
O.Free;
end;

there were at least 32 bytes allocated for a second? (Not that it matters,
I could be wrong, etc.)

        Ah - I see that there's no Pascal code in system.TObject.Create.
But the compiler can still do something - it knows there's something to
be done because Create is a constructor. (?)

--
David Ullrich

?his ?s ?avid ?llrich's ?ig ?ile
(Someone undeleted it for me...)

Re:Compiler thinks Class = Record!


Quote
David Ullrich wrote:

> Tim Roberts wrote:
> > [...]

> > Sorry, but you are mistaken.  TObject DOES define a default Create
> > constructor, which does nothing; that happens to be an adequate
> > functionality for many classes.  Check source\rtl\sys\SYSTEM.PAS.  There
> > are several examples of classes in the VCL which derive directly from
> > TObject and do not define their own Create.  TList is one example.

>         Surely TObject.Create does more than nothing, like for example
> it allocates space for the object's fields? If I say

> var O: TObject;
> begin
> end;

> and the optimizer's having a bad day that object should take 4 bytes,
> while if I say

> var O: TObject;
> begin
> O:= TObject.Create;
> O.Free;
> end;

> there were at least 32 bytes allocated for a second? (Not that it matters,
> I could be wrong, etc.)

>         Ah - I see that there's no Pascal code in system.TObject.Create.
> But the compiler can still do something - it knows there's something to
> be done because Create is a constructor. (?)

The word constructor implies a call to NewInstance and InitInstance if
the constructor is called as a method of a class. Afterwards, the actual
method code is called.

If the constructor is called as a method of an object, there are no
special handling.

Therefore it is e.g. syntactically valid to do

  MyObj := TMyObj.Create;
  .
  .
  MyObj.Create;

Memory will only be allocated in the first of these lines.

But, even though it is legal to use this construct, I believe most of
the VCL would {*word*88} on having the constructor called as a method, a lot
of internal allocations normally happen in constructore.

BTW. All of this is taken from the back of my memory, it is very well
possible that it's not entirely correct or changed since D1...

Regards,

Erik.
--
Independent contracting - Development of applications and drivers
for DOS, Win 3.1, Win 95, Win NT.

Visit http://www.info-pro.no/sperling for some free Delphi source.

Erik Sperling Johansen <e...@info-pro.no>

Other Threads