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:
- Pick the most convenient unit (A) to be used by the other (B).
- Place all variables that must be shared between these units into A.
- 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