Michael Van Canneyt
michael at freepascal.org
Tue Feb 1 09:43:17 CET 2005
On Tue, 1 Feb 2005 uberto at gama-soft.com wrote:
> I'm going to port IO (www.instantobjects.org) to fpc.
> The codebase is quite large (about 30000 lines of code) and I don't really
> know fpc, but I hope I'll understand it better at the end of the story. ;)
> I'm in touch with IO main developers so there's no problem to slightly change
> IO code for compatibility.
> I tried first to compile it commenting problematic parts, all in all there
> are very few problems.
> I'm not sure fpc attitude to Delphi compatibility, also regarding IP
> problems. So I list here what I found, please tell me what I can submit as
> bug, and what is yet differently implemented (or intended to be so).
> I tested with a Lazarus build 0.9.4 (3/1/05) under win32, maybe it'd be
> better testing with fpc only and a cvs version but I was interested in it as
> a proof of concept.
> 1 - delphi has TRecStringRec and PRecStringRec, used by (among others)
> Exception.CreateRes(); fpc has PString that is different.
This could be added for compatibility's sake.
> 2 - delphi allows for a resourcestring to be passed by address
> (@MyResourceString), fpc don't.
Unfortunately, resource strings don't work like that in FPC. I don't
think it will be possible to change this.
> 1 - curiously fpc TCollection hasn't a remove or delete method, delphi
> TCollection has it. [maybe I did't find it]
I have added delete
> 1 - delphi TFiler has an internal Stream, TReader and TWriter use it and
> expose Position, Read, Write and other methods that use it; fpc TFiler
> hasn't. [in this case maybe fpc has the right approach btw]
This will not be changed. FPC has a different architecture, which allows
for different reader/writer backends; Position, read and Write are not
relevant for some backends, so these methods/properties will not be
> 2 - delphi has TWriter.WriteStr (which is different from WriteString that use
> AnsiString), same with TReader.ReadStr; fpc hasn't.
I don't see the point of adding this except for compatibility's sake.
Personally, I think Borland left it for compatibility with Delphi 1.
> 3 - delphi TStream has a FlushBuffer method; fpc hasn't. [which is curious
> and potentially slower]
? TStream in D5 does not have this. It also makes no sense to have this, since
TStream does not have a buffer. TFiler does have it, but see point 1 for this.
> 4 - delphi TReader.ReadChar/TWriter.WriteChar use a char (1 byte); fpc use a
> string (6 byte at least).
See point 1, although maybe we can do something about this.
> 1 - delphi TPropInfo.PropType is PPTypeInfo; fpc TPropInfo.PropType is
> PTypeInfo (a direct pointer instead of a pointer of pointer). [Are there
This can be changed.
> 1 - fpc lacks VarClear() function. [It exists but it's not public]
Can be added.
> 1 - fpc lacks a TCustomConnection abstract class. [Delphi TCustomConnection
> is not really abstract but it doesn't do anything anyway]
This can be added, but is obsoleted by TDatabase. Maybe it can be
> 2 - fcp TDataset lacks locate method. [I don't checked for an equivalent]
Because variants are not finished.
> 3 - Delphi TFieldDefs.Update is a boolean property; fpc TFieldDefs.Update is
> a procedure.[Trivial to fix anyway]
> 1 - fpc lacks a HexToBin and BinToHex functions. [It has them but only as
> private methods of TParser]
These functions are in sysutils or strutils. They have no place in
> 2 - TStringListSortCompare function type differs. [Trivial to fix]
I'd need to check this.
> 1 - I think fpc lacks run-time packages support. [If I'm mistaken I have to
> study it better. Anyway it's not a real problem]
This is correct, and is planned, but don't hold your breath.
> As you can see there's nothing really serious, I can contribute code if you
> tell me.
> I hope IO will be useful to fpc and lazarus projects.
I'm sure it will be. Feel free to send patches to me for anything you
think needs fixing.
More information about the fpc-devel