[lazarus] Possible compiler bug with derived classes?

[Chris Storah]

I haven't committed myself to a particular component set yet, but thanks for
the warning.
Only just managed to get the compiler re-compiling!
I may take a look at TGrid, unless it has been covered by anyone else -
since I have written grid classes in the past (C++).

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