Grant Jacobs gjacobs at
Thu Mar 6 01:43:33 CET 2003

At 3:54 PM -0800 5/3/03, Frank D. Engel, Jr. wrote:
>Consider that it might be nice, though, to split those into separate
>units for a different reason: the file might be very large.

Basically, this is the example Peter used earlier.

>For example, what if I create an opaque type, say "Color", and another
>opaque type, say "ColorSystem".  For simplified management, I may
>choose to place each of these in a different source file, even though
>they should obviously depend on resources in each other's domain.  The
>possibilities for correcting this would be to take those "common"
>resources and place them in some third file (messy),

This is in broad essence what I've done (I'm in a bit of a hurry; I 
just want to get an initial port the *work* at all to start with!). 
Basically, for each module/unit XXX with circ. refs. I've made a 
XXXUtils module/unit which holds the stuff which can be used by other 
modules/units, although I've done without the pointers you mention 
below as I don't need them.

>to use circular
>references (undesirable), or the following:
>1. Pick the most convenient unit (A) to be used by the other (B).
>2. Place all variables that must be shared between these units into A.
>3. For every function in A that must be accessable by B, create a
>function pointer type in A, along with a interface-level variable of
>that type.
>4. In the initialization part of B, assign the functions' addresses to
>those variables.
>A bit messy at first read, but I've become used to it...

For the global error message system on the other hand I made an error 
function handler which receives each unit's error function as a 
parameter. But that's a bit of a unique case and its partly to handle 
porting code with more than one error function in different units.

Grant Jacobs Ph.D.                                     BioinfoTools
ph. +64 3 476 1820  (office, after 10am)               PO Box 6129,
or  +64 25 601 5917 (mobile)                               Dunedin,
gjacobs at                               NEW ZEALAND.
    Bioinformatics tools: deriving knowledge from biological data
Bioinformatics tools - software development - consulting - training
Check out the website for more details:

The information contained in this mail message is  confidential and
may  be legally privileged. Readers of this message who are not the
intended recipient are hereby notified that any use, dissemination, 
distribution or reproduction of this message is prohibited. If  you
have received this message in error please notify the sender immed-
iately and destroy the original message.  This applies also to  any
attached documents.

More information about the Gpc mailing list