Consider that it might be nice, though, to split those into separate units for a different reason: the file might be very large.
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), 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...
--- Frank Heckenbach frank@g-n-u.de wrote:
Grant Jacobs wrote:
At 2:17 AM +0100 5/3/03, Frank Heckenbach wrote:
Grant Jacobs wrote:
Somewhat ironically for someone who has been talking about hierarchial unit models, I've run into this circular reference
thing
a few times in the code I'm porting. I ended up creating
separate
sub-units to resolve the issue.
Sorry to be annoying again, but it was you who talked about hierarchical unit models:
I know that! - I talking about myself, not you!!
I see, sorry.
BTW, though I don't like the "unit inheritance", I don't like circulare references either -- IMHO, if two units require each other, they actually form one "unit" (in the non-technical meaning of the word), and splitting them into two files seems quite pointless. It might be a way to have different users get different parts only, but for that, a module with several interfaces seems cleaner and more flexible (interfaces can overlap, e.g.) ...
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: 51FF C1F0 1A77 C6C2 4482 4DDC 117A 9773 7F88 1707
===== ======= Frank D. Engel, Jr.
Modify the equilibrium of the vertically-oriented particle decelerator to result in the reestablishment of its resistance to counterproductive atmospheric penetration.
__________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/