> Michael Van Canneyt wrote: > > > > I'm willing to demonstrate my ideas in a redesign and extension of > > > Abbrevia, so that we have a concreter base for further discussions. But > > > before starting with that work I would like to hear some encouraging <g> > > > opinions or suggestions. > > > > I think you can do this. I will be pleased to help where I can. > > But send a proposal before you start, I wouldn't want to you > > end up rewriting half your code after a discussion. ;-) > > Here some comments and questions about the Abbrevia port. > > 1) Conditionals > I've redesigned the AbDefine.inc file, with two important changes:
You might also want to have a look at http://www.stack.nl/~marcov/porting.pdf and http://www.stack.nl/~marcov/unixrtl.pdf > Question: Rename all files? All lowercase...? > > The LINUX symbol can clash with the according FPC symbol. It should be > renamed e.g. into KYLIX - does somebody know what Kylix defines for > itself? A combination of ver<x> and linux, as Michael said. There are 4 cases for Unix: 1 Kylix 2 FPC/Linux/x86 reusing Kylix libc code. 3 FPC/Linux/x86 using general FPC unix code 4 Other FPC Unix targets using general FPC unix code Since 1->2 is an easy port often, so I think in general FPC/Linux/x86 should remain switchable between "libc" and "FPC-UNIX" mode. > Question: How to use the FPC provided target symbols? See the "porting" guide. I try to adhere to it, and so does JEDI. > I'm not happy with the UNIX keyword, I'd used POSIX instead. But that's > only my opinion, I don't want to introduce another symbol. As Michael said, that was already discussed. > I'm also not familiar with the differences between the Unix/POSIX > systems. Unix is supposed to be a superset. However one of the main reasons is to avoid standards picking. > 2) File Restructuring > I've separated the spaghetti code in AbUtils.pas into distinct MSWINDOWS > and UNIX sections, each containing complete procedures. These sections > could be moved into dedicated OS specific include files - what's the > preferred way? I (and FPC in general) prefer that. Jedi prefers to ifdef ad infinitum, they are (used to be is a better word) afraid of include files. > According to my first impression of the Abbrevia coding conventions I'd > prefer to use the existing and better ported and portable code in the > already existing paszlib and bzip2 libraries, instead of porting the > according Abbrevia implementations. Perhaps the whole de/compressor part > of Abbrevia could be reduced to the base classes, from which inherit the > new wrappers for the FPC ports. > > Question: What's preferrable, a direct port of the Abbrevia library, or > a new and better portable design instead, that interfaces with the not > otherwise available worker classes as implemented in Abbrevia? Since the answer varies wildly with the amount of work the implementor wants to invest, I guess my answer would be "that is up to the implementor". To me, a clean interface with zlib that is switchable between shared lib and paszlib is a pre. I always liked that in the old situation. Partially also because paszlib is still slower. > 3) Data Types > "off_t" now replaces the Integer/LongInt/Int64 mess, for all file size > related values. I took this name from the C standard, but perhaps it > should be replaced by some Pascal name? FPC still got to acquire a native form of 64-bit filesupport. I think using an identifier that is not likely to clash with existing types is preferable. So that rules out off_t (which is used by Unix internally). Later when FPC has a system for 64-bit fs, we can assign the type to an invariant that has the right size for FPC's filesystem. (64-bit on new systems, 32-bit on legacy) > IMO this type also should be used in the TStream classes, replacing the > current conditional distinction (seek64bit) between 32 and 64 bit > methods. Why write two implementations, when the compiler can use the > actual type definition immediately? I'm in favour of simply making the whole FPC file implementation 64-bit, regardless of 64-bit OS support or not. > "DWORD" will be replaced by cUInt32 (or equivalent - what?), as far as > this type is used outside dedicated MSWINDOWS code. On *nix, the unixtype unit defines these. > The 16 bit "word" datatype IMO should not be used in 32 bit code, unless > where required in datastructures with a fixed layout. True. > 4) Exceptions, Error Codes etc. > IMO it would be sufficient to use one general exception class for the > de/compression errors. An application cannot draw any advantage from > many specialized exception classes, and exception handlers inside a > specific class can use the class specific error code in the exception > object. I think it would wise to not use exceptions too deep in the code. Compression is one of those things where OOP and exception overhead still count. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
