Hi,
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.

ResourceString:
1 - delphi has TRecStringRec and PRecStringRec, used by (among others) Exception.CreateRes(); fpc has PString that is different. 2 - delphi allows for a resourcestring to be passed by address (@MyResourceString), fpc don't.

TCollection:
1 - curiously fpc TCollection hasn't a remove or delete method, delphi TCollection has it. [maybe I did't find it]

Streams:
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] 2 - delphi has TWriter.WriteStr (which is different from WriteString that use AnsiString), same with TReader.ReadStr; fpc hasn't. 3 - delphi TStream has a FlushBuffer method; fpc hasn't. [which is curious and potentially slower]
4 - delphi TReader.ReadChar/TWriter.WriteChar use a char (1 byte); fpc use a string (6 byte at least).

RTTI:
1 - delphi TPropInfo.PropType is PPTypeInfo; fpc TPropInfo.PropType is PTypeInfo (a direct pointer instead of a pointer of pointer). [Are there equivalent?]

Variants:
1 - fpc lacks VarClear() function. [It exists but it's not public]

Db:
1 - fpc lacks a TCustomConnection abstract class. [Delphi TCustomConnection is not really abstract but it doesn't do anything anyway] 2 - fcp TDataset lacks locate method. [I don't checked for an equivalent] 3 - Delphi TFieldDefs.Update is a boolean property; fpc TFieldDefs.Update is a procedure.[Trivial to fix anyway]

Classes:
1 - fpc lacks a HexToBin and BinToHex functions. [It has them but only as private methods of TParser]
2 - TStringListSortCompare function type differs. [Trivial to fix]

Packages:
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]

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.

Bye Uberto

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.

TCollection: 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

Streams: 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 added.

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.

This can be changed.

Variants: 1 - fpc lacks VarClear() function. [It exists but it's not public]

Can be added.

Db: 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 aliased.

2 - fcp TDataset lacks locate method. [I don't checked for an equivalent]

Because variants are not finished.

These functions are in sysutils or strutils. They have no place in Classes.

2 - TStringListSortCompare function type differs. [Trivial to fix]

I'd need to check this.

Packages: 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.

Michael.

I started these, but are now to busy now to test, if sb is bored:

http:/www.stack.nl/~marcov/bintohex.txt

1.9.7 from cvs supports it.

Why don't you use a translation table to convert character to hex? The conversion table can be shared with other information like flags "is upper", "is lower", "is alpha", "is hex", "is digit".

Shouldn't the binvalue in BinToHex be increased only by 1 instead of current 2 ?
inc(binvalue,2);

Jan

The conversion table can be shared with other information like flags "is upper", "is lower", "is alpha", "is hex", "is digit".

Large table and except digit and hex the rest is locale dependant.

Shouldn't the binvalue in BinToHex be increased only by 1 instead of current 2 ? inc(binvalue,2);

I think so yes. hextobin should increase with 2, so bintohex with 1

Ok, now I'll download fpc from cvs and I'll create some wrapper classes for Streams.
Note that IstantObject code now is terribly mingled between visual and persistent part. I'm working also on that.

Bye Uberto

please note that the code is yet present in TParser. I suggest to remove it from there and put it only on strutils.

Bye Uberto

Ok, now I'll download fpc from cvs and I'll create some wrapper classes for Streams.
Note that IstantObject code now is terribly mingled between visual and persistent part. I'm working on that too.

Bye Uberto

please note that the code is yet present in TParser. I suggest to remove it from there and put it only on strutils.

Bye Uberto

Hi,

I am porting CLX to FPC.

Some time ago, when I created a Qt/Embedded binding for FPC, Qt.pas did not compile anymore due to some changes in FPC. The error was:
Can't declare procedure as EXTERNAL

See also:
http://www.nl.freepascal.org/lists/fpc-pascal/2004-December/007738.html

I created a tool to move the declarations to the interface, but now I notice that FPC does not give an error anymore. Is the problem solved or should I still for safety move the declarations to the interface section ?

kind regards,

Den Jean

It is the best to have the external declarations in the interface. If the external references are in the implementation section it might be that fpc generates a stub that calls the external reference.

I almost finished the porting of the core part of IO to fpc.

I added bugs for the (few) function I had to rewrite or modify passing from Delphi to fpc.

Anyway I'm still in trouble with streams.
IO use descendants of TRead and TWrite like files. It goes back when an error rises and it needs reading/writing block of binary data.

Someone could point me the best way to add similar behavior over fpc TRead and TWrite?
It could be added to the "driver"?

Another problem that could arise is that the same data could be saved and restore differently between fpc and delphi. In this case it'd be not possible to share config files. Annoying but not dramatic.

Bye Uberto

Uberto Barbini wrote

I almost finished the porting of the core part of IO to fpc.

I am *very* interested in seeing this working :)

What is TRead and TWrite ?

Could you explain this ?

Another problem that could arise is that the same data could be saved and restore differently between fpc and delphi. In this case it'd be not possible to share config files. Annoying but not dramatic.

You should write using text files only if you need this.

There is no binary compatibility when writing data from memory to file. Maybe if you use packed records and packed arrays, but by default alignment is different. I am also not sure about floating point values...

Michael.

> I almost finished the porting of the core part of IO to fpc. I am *very* interested in seeing this working :)

Nice to know! ;)

mmh, I meant TReader and TWriter, the stream classes descendants of TFiler.

> It could be added to the "driver"? Could you explain this ?

I could explain better later, with some code.
Anyway I noted that fpc use a smarter strategy than delphi: instead of an internal TStream fpc use a "Driver", an internal object delegated to all read/write operations.
I'm not sure how could it made compatible with IO needs.

You should write using text files only if you need this.

Yes, I agree.
Maybe there were some minor issues with text too anyway (like cr/lf or floating point formats).

Bye Uberto