[fpc-pascal]Class Identification?

memsom at interalpha.co.uk memsom at interalpha.co.uk
Mon Mar 24 15:01:07 CET 2003

To expand on Sebastians answer...

> 2. Will TObject remain the "default ancestor" in the future?

Yes, beacuse the Object Pascal that FPC supports is based on Borland Delphi's 
Object Pascal language (which is in part related to the Object Pascal standard 
created by the ISO or ANSI, I forget whuch one exactly.) Borland now have the 
defacto industrial standard Object Pascal implementation in the version of 
Object Pascal supported by Delphi. There are at least 3 compilers that support 
it, targetting multiple platforms (Delphi/Kylix, FPC, Virtual Pascal, and there 
a number of developers working on PDA versions of Object Pascal), on 10+ 
platforms. The only way it could change would be for Borland to lead the way. I 
believe even Delphi.NET is able to see the .NET 'Object' to be a 'TObject'.
> 3. Efficiency: Sometimes I use classes without ancestor, with the assumption, 
> that this might be more efficient in cases where TObject's methods and fields 
> are not necessary. It seems that assumption was wrong. To save resources, 
> should I use explicite pointers to objects when I don't need the features 
> inherited by the class TObject?

Write a procedure or function that takes a 'self' pointer to the data. This is 
basically what methods are at the end of the day. 

If you want better allocation performance, you can always refactor the memory 
allocation routines too. If FPC follows Delphi's model, there will be a record 
that holds the memort allocation routines. Have a look for the record type 
TMemoryManager that will probably be located in System or Sysinit unit. 
Altering the way these routines work can greatly improve speed and resource 

One other point.... you really should use 'is' and not 'MyObject.ClassType'. 

 if ( myinst is TButton ) then begin

looks less ugly than:

  if ( myinst.ClassType = TButton ) then ... ;

This is held up by the statement int he Borland help:

> function ClassType:
> Description: ClassType dynamically determines the type of an object. It is 
> used internally by the is and as operators.
> Note:	Applications should rarely, if ever, call ClassType directly.  Instead, 
> use the is or as operator.

Whether there is currently a good reason or it is just stylistic, I believe 
it's better to use the recognised syntax of a language rather than a convenient 
loophole. Just as TObject will stay with us forever now in it's current form, 
so will the 'is' and 'as' operators. 



This message was sent using Mistral WebMail.

More information about the fpc-pascal mailing list