On Sat, 1 Jan 2005, DrDiettrich wrote:
> In the meantime I downloaded the Abbrevia package from SourceForge, and > came across several unpleasent constructs. Please let me introduce my > preferred programming model for portable code. > > 1) Target Dependencies > I don't accept any OS or machine specific conditional compilation in > code, except in dedicated units. In Abbrevia the same fixes occur in > various places in the code, instead of in a dedicated OS specific > procedure. Such a procedure exists, but unfortunately only in the > unpatched form :-( > Also compiler specific conditionals should be used only where absolutely > necessary (local options, syntax differences...). Agreed 100%. In general, a component suite should have all os-dependent code in a single unit, presenting the rest of the suite with a uniform API. > > 2) Code Checks > It should be possible to check code for compilation on other platforms. > This requires that target specific code can be compiled on any host, > somehow. Consequently it must be possible to override the compiler > generated symbols that describe the environment. Why, you can simply cross-compile ? > > 3) Standard Units > Portable code shall use standard procedures and units for target > specific actions. This requires the definition, implementation, and > consequential use of one or more standard units for: > - Machine specific data types and procedures (endianness...) Compiler defines the endianness. System unit has 'guaranteed' types. > - OS specific data types and procedures ? This is not portable. > - C and POSIX specific data types (for code ported from GNU/C) > Then it should be clear which portable data types and procedures should > be taken from which unit. It also should be easier to determine which > procedures need special considerations in portable code, from the > defined data types and procedures in these units. > > It's not necessary that everybody follows these principles, but I will > do so in my own published portable code. Otherwise I can continue to > write my code for Delphi, and let it to somebody else to port that code > to e.g. FPC. > > In the simplest case these units will have an unconditional interface > part, the target specific data type declarations and the implementation > part can be included conditionally from the appropriate locations. For > testing purposes fake units or code sections can contain the OS specific > procedure declarations, with empty bodies. This way I could verify that > my changes to the main stream code would not break the code for other > environments, due to the use of not yet ported constants or data types > etc. > > This model has one disadvantage, in so far as complex procedures with > small embedded platform specific code could no more be checked, because > it often was impossible to determine the impact of changes to local > variables etc. in the conditionally excluded code. It also was and is > impossible to automatically verify that the conditional sections really > are implemented for every target! > > In another implementation of a target independent library I defined > portable classes with standardized methods. These virtual methods were > almost abstract in the base class, so that they had to be overridden in > every derived class. In the initialization section of the unit the > appropriate class was created and assigned to the according variable, > based on the actual or desired target environment. Of course this > approach has the disadvantage of increasing runtime (how much?), due to > the virtual method calls. Nonetheless I think that in many cases the > difference from the traditional method will not be noticeable, due to > the (unknown, long?) runtime spent in the embedded OS calls. > > The best compromise might be a mix of both methods. The interface can be > fully procedural, and objects with virtual methods are used only in the > implementation part, and only when this approach makes sense. Perhaps > somebody finds another way to achieve the same goal, with less > disadvantages? > I don't think you should worry about virtuals. For archiving purposes, it's the compression/decompression algorithms that will take most time, and tha actual reading/writing from stream. > > 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. ;-) Michael. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel