the@mit-caf.MIT.EDU (Siang-Chun The) (01/20/90)
I have one Turbo Pascal unit that I want to completely hide within another unit. The inner unit to be hidden has an automatically updated status variable that I want to be accessible to users of the outer unit, eg. unit inner; interface var stat : integer; implementation (* * inner details... *) end. and the outer unit is unit outer; interface var status : integer absolute inner.stat; implementation (* * details.. *) end. But this fails to compile: I think the compiler just hangs (it's been some time since I last tried this experiment). Has anyone else tried to do anything similar, with success? Why does it fail? Siang-Chun The the@caf.mit.edu
dhinds@portia.Stanford.EDU (David Hinds) (01/20/90)
In article <3757@mit-caf.MIT.EDU>, the@mit-caf.MIT.EDU (Siang-Chun The) writes: > I have one Turbo Pascal unit that I want to completely hide within > another unit. The inner unit to be hidden has an automatically updated > status variable that I want to be accessible to users of the outer unit. Your example might fail because references to addresses in other units can't be resolved in a unit's interface section. Though it wouldn't serve your purpose, you could see if the compiler dies when the declaration is in the implementation part of the unit. Simple workarounds would be to declare a pointer in the outer unit interface section which the body of the unit sets to point to the status variable in the inner unit. Or you could declare a parameterless function in the outer unit, which just returns the value of the status variable. - David Hinds dhinds@portia.stanford.edu
pmk@cip-s01.informatik.rwth-aachen.de (Michael Keukert) (01/20/90)
In article <3757@mit-caf.MIT.EDU> the@mit-caf.UUCP (Siang-Chun The) writes: > > unit outer; > interface > var > status : integer absolute inner.stat; > implementation > (* > * details.. > *) > end. > Try instead: UNIT outer; INTERFACE CONST status:INTEGER = inner.stat; IMPLEMENTATION Doing this, you declare outer.status as a typed constant which means, this is a "normal" variable but with a defined value within the code. ABSOLUTE is only valid with a memory-adress for example VAR somewhere_in_memory ABSOLUTE $c000:0000; which means, that the variable somewhere_in_memory contains always the value in memory-cell $c000:000. OK? -------------------------------------------------------------------------- Michael Keukert, Elsasstrasse 58, D-5100 Aachen 35, Phone: +49 241 513297 Twenty bucks per day plus expenses, hundred in advance. (Sam Spade)
kherron@ms.uky.edu (Kenneth Herron) (01/23/90)
In episode <2013@rwthinf.UUCP>, we heard pmk@cip-s01.UUCP (Michael Keukert) say: |In article <3757@mit-caf.MIT.EDU> the@mit-caf.UUCP (Siang-Chun The) writes: |> |> status : integer absolute inner.stat; | |Try instead: | | UNIT outer; | | INTERFACE | | CONST status:INTEGER = inner.stat; | | IMPLEMENTATION | |Doing this, you declare outer.status as a typed constant which means, |this is a "normal" variable but with a defined value within the code. | |ABSOLUTE is only valid with a memory-adress for example | | VAR somewhere_in_memory ABSOLUTE $c000:0000; | |which means, that the variable somewhere_in_memory contains always |the value in memory-cell $c000:000. | |OK? BZZT! Wrong, but thanks for playing... Your alternative suggestion won't work. Inner.stat is a variable, so at compile-time, when status is initialized, inner.stat has no value. Further, any changes to inner.stat as the program runs would not be reflected in status. Your example would work if the declaration made status use the same memory location as inner.stat. Your comments about ABSOLUTE are also wrong. You can give a variable name in place of the address, in which case the new variable being defined is aliased to the same memory location as the original variable. This is, in fact, the correct way of doing what you seem to be trying in your counterexample (except that evidently it doesn't work across unit boundaries). Disclaimer: The latest version I have programming experience with is TP 4.0; from what I've heard about the later versions, the above facts should still be correct. Kenneth Herron