[lazarus] Possible compiler bug with derived classes?

Michael Van Canneyt michael.vancanneyt at wisa.be
Thu Nov 4 07:13:29 EST 1999




On Thu, 4 Nov 1999, Chris Storah wrote:

> Sorry, Value isn't a problem - I suddenly lost the ability to read code :-)
> 
> Why does the compiler error with the parameters of the constructors?
> If this is the case, code porting will be a nightmare since a lot of code
> will use 'Create' with the same parameter list as the base class?

? Shouldn't you use 'override' or something like that ? Or at least
make it virtual ?

Michael.
> 
> Chris
> 
> -----Original Message-----
> From: Michael Van Canneyt [mailto:michael.vancanneyt at wisa.be]
> Sent: 04 November 1999 11:21
> To: lazarus at miraclec.com
> Subject: RE: [lazarus] Possible compiler bug with derived classes?
> 
> 
> 
> 
> On Thu, 4 Nov 1999, Chris Storah wrote:
> 
> > Just found a piece of code that may or may not clarify things:
> > (TField sample in the Delphi help)...
> > 
> > Problem is not limited to variables - constructors have the same problem
> if
> > the parameters names conflict.
> > 
> > The compiler gets conflicts for FNAME, X anf Y, but not Value - why has
> > Value got through, as it's name is re-used?
> 
> Where is it re-used ? I don't see it ? Once in TStrField and once in
> TNumfield
> which don't depend on each other.
> 
> BTW. I see you used TDataset stuff as examples; If you're writing TDataset
> stuff: There is a TDataset with TField implementation available for Free
> Pascal in the FCL. It provides Read-only access; there are 2 descendants:
> one for a dataset in a flat file, one for accessing a MySQL database.
> I have the plans for scalable TDatasets ready
> (I mean TTable and TQuery that work on any database)
> 
> Just so you don't implement things that already exist :-)
> 
> Michael.
> 
> 
> > 
> > Cheers,
> > Chris.
> > 
> > {================================}
> > TField = class
> > private
> >   X, Y, Len: Integer;
> >   FName: String;
> > public
> >   constructor Copy(F: TField);
> >   constructor Create(FX, FY, FLen: Integer; FName: String);
> >   destructor destroy; override;
> >   procedure Display; virtual;
> >   procedure Edit; dynamic;
> > protected
> >   function GetStr: String; virtual;
> >   function PutStr(S: String): Boolean; virtual;
> > private
> >   procedure DisplayStr(X, Y: Integer; S: String);
> > public
> >   property Name: String read GetStr write Buffer;
> > end;
> > 
> > 
> >   TStrField = class(TField)
> >   private
> >     Value: PString;
> >   public
> >     constructor Create(FX, FY, FLen: Integer; FName: String);
> >     destructor Destroy; override;
> >   protected
> >     function GetStr: String; override;
> >     function PutStr(S: String): Boolean; override;
> >   end;
> > 
> >   TNumField = class(TField)
> >   private
> >     Value, Min, Max: Longint;
> >   public
> >     constructor Create(FX, FY, FLen: Integer; FName: String;
> >       FMin, FMax: Longint);
> >     function GetStr: String; override;
> > 
> >     function PutStr(S: String): Boolean; override;
> >     function Get: Longint;
> >     procedure Put(N: Longint);
> >   end;
> > 
> > {===================================================}
> > 
> > 
> > -----Original Message-----
> > From: Michael Van Canneyt [mailto:michael.vancanneyt at wisa.be]
> > Sent: 04 November 1999 09:32
> > To: Lazarus (E-mail)
> > Subject: Re: [lazarus] Possible compiler bug with derived classes?
> > 
> > 
> > 
> > 
> > On Thu, 4 Nov 1999, Chris Storah wrote:
> > 
> > > I am having problems when compiling a derived class (WinNT version).
> > > This is the code:
> > > 
> > >   TVer1 = class(TObject)
> > >       protected
> > >          rec: TObject;
> > >    end;
> > > 
> > >   TVer2 = class(TVer1)
> > >       protected
> > >          rec: TObject;	<=== duplicate identifier
> > >       end;
> > > 
> > > 
> > > The error using ppc386 is 'Error: Duplicate identifier REC'.
> > 
> > This IS an error; if you declare such a thing in the protected
> > part, you should rename it. How is the compiler supposed to
> > know in a descendent class which one to take ? Any decision will
> > be necessarily an arbitrary one.
> > 
> > > Is this a known bug?
> > > If so, anyone know how to fix it without changing the identifier names
> > > (Delphi works with the above code).
> > 
> > Delphi has other strange quircks; Can you tell me WHICH rec it takes
> > when you refer to it ?
> > 
> > I agree that for the sake of compatibility, we should accept this, but it
> is
> > simply bad programming to do this, so this is not a priority.
> > 
> > Michael.
> > 
> > _________________________________________________________________
> >      To unsubscribe: mail lazarus-request at miraclec.com with
> >                 "unsubscribe" as the Subject
> >     archives at http://www.miraclec.com/list_archives/lazarus
> > 
> > _________________________________________________________________
> >      To unsubscribe: mail lazarus-request at miraclec.com with
> >                 "unsubscribe" as the Subject
> >     archives at http://www.miraclec.com/list_archives/lazarus
> > 
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>     archives at http://www.miraclec.com/list_archives/lazarus
> 






More information about the Lazarus mailing list