deangran@cacofonix.cs.uoregon.edu (Dean Micheal Grandquist) (01/15/91)
I am tring to resolve two questions that came up durring a Modula2 symantics lecture. Is the Available() procedure in Storage "standard" (according to Whirth)? Also if a pointer is unset will SIZE(ptr^) return the size of what ptr points to? Thanks Dean Grandquist deangran@cs.uoregon.edu
GRANGERG@VTVM1.BITNET (Greg Granger) (01/15/91)
On Tue, 15 Jan 91 04:36:11 GMT <editor%ucf1vm.BITNET@LILAC.BERKELEY.EDU> said: > I am tring to resolve two questions that came up durring a Modula2 >symantics lecture. Is the Available() procedure in Storage "standard" While Available(), is in PIM2 (3th ed) it is stated: These modules are presented here in the form of definition modules. We emphazise that they are NOT part of the definition of the LANGUAGE Modula-2, and it is recognized that different implementations may be either vary in details or in the selection of modules provided. This BTW includes the following modules: Terminal, FileSystem, InOut, RealInOut, Windows, TextWindows, GraphicWindows, CursorMouse, Menu, Storage and MathLib0. >(according to Whirth)? Also if a pointer is unset will SIZE(ptr) return the >size of what ptr points to? >... > Dean Grandquist If a pointer is "unset" (by that I assume you mean DEALLOCATEd), it doesn't point to anything, therefore whatever SIZE might return would have no meaning. You can of course call SIZE on the type of the pointer and get the size that it would require. As far as I could tell (and I didn't look that close) SIZE is not defined in the case of a pointer being NIL or undefined, although it might be reasonable to assume it would return 0 in the case of the former; what it returns in the case of the former is entirely up to the compiler writer and how the heap was implemented. Greg
brandis@inf.ethz.ch (Marc Brandis) (01/16/91)
In article <INFO-M2%91011516471353@UCF1VM.BITNET> Modula2 List <INFO-M2%UCF1VM.BITNET@ucf1vm.cc.ucf.edu> writes: >>(according to Whirth)? Also if a pointer is unset will SIZE(ptr) return the >>size of what ptr points to? >If a pointer is "unset" (by that I assume you mean DEALLOCATEd), it >doesn't point to anything, therefore whatever SIZE might return would >have no meaning. You can of course call SIZE on the type of the >pointer and get the size that it would require. As far as I could >tell (and I didn't look that close) SIZE is not defined in the case >of a pointer being NIL or undefined, although it might be reasonable >to assume it would return 0 in the case of the former; what it >returns in the case of the former is entirely up to the compiler >writer and how the heap was implemented. SIZE is most often (in fact, in each compiler that I know of) implemented as the size of the type. That is, the compiler evaluates the type of the expression that stands inside the parentheses and then replaces the SIZE(expression) by the size of this type, which is a constant. This means especially that SIZE(expression) is never dependent on the actual value of the expression. In the above case, it means that it does not make any difference whether the pointer is NIL or not, the result is always the size of the type to which the pointer type is declared to point to. Marc-Michael Brandis Computer Systems Laboratory, ETH-Zentrum (Swiss Federal Institute of Technology) CH-8092 Zurich, Switzerland email: brandis@inf.ethz.ch
news@m2xenix.psg.com (Randy Bush) (01/26/91)
Jon.Guthrie@p15.f20.n226.z1.fidonet.org (Jon Guthrie) writes: > All I want to do is be able to assign any quantity of type ADDRESS to an > opaque type. I also want to be able to test an opaque type for equality to > NIL. Sorry to miss your original point and blather on about uninitialized opaque detection. You could get dirty and try the old type transfer hack OpaqueInstance := OpaqueTypename(address) and OpaqueInstance = OpaqueTypename(NIL) What you really want is the new TRANSLUCENT type extension which is being proposed by a subgroup of the BSI. :-) -- ..!{uunet,qiclab,intelhf,bucket}!m2xenix!news
RESLERD%UL.IE@UCF1VM.CC.UCF.EDU (Dan Resler) (01/29/91)
Somebody has said (in response to Jon.Guthrie): >What you really want is the new TRANSLUCENT type extension which is being >proposed by a subgroup of the BSI. :-) >-- >!{uunet,qiclab,intelhf,bucket}!m2xenix!news ^^^^^^^^^^^^????? And who is this masked-man slandering the good folks in the BSI group? ;-) Dan Resler Dept. of Electronics & Computer Engineering, University of Limerick, Ireland email: RESLERD@UL.IE voice: 061-333644 x2173 FAX : 061-330316
torbjorn@forit.forut.no (Torbjorn Sund) (01/30/91)
Jon.Guthrie@p15.f20.n226.z1.fidonet.org (Jon Guthrie) writes: > All I want to do is be able to assign any quantity of type ADDRESS to an > opaque type. I also want to be able to test an opaque type for equality to > NIL. Who says that an opaque type is assignment or storage equivalent to ADDRESS? At least one compiler (FTL) did not impose the restriction that an opaque type be implemented as a pointer. Torbjorn Sund Norwegian Telecom
warwick@batserver.cs.uq.oz.au (Warwick Allison) (01/31/91)
In <1991Jan30.091656.4348@mack.uit.no> torbjorn@forit.forut.no (Torbjorn Sund) writes: >Jon.Guthrie@p15.f20.n226.z1.fidonet.org (Jon Guthrie) writes: > >> All I want to do is be able to assign any quantity of type ADDRESS to an >> opaque type. I also want to be able to test an opaque type for equality to >> NIL. > >Who says that an opaque type is assignment or storage equivalent to ADDRESS? >At least one compiler (FTL) did not impose the restriction that an >opaque type be implemented as a pointer. That's right, opaque is OPAQUE - It represents a level of abstraction, which you cannot circumvent, you shouldn't really be using assignment operations with an opaque type. If you need some sort of ADDRESS from the opaque type, then the module exporting the type should given you a function to do that, if not, then you should make NO ASSUMPTIONS about the opaque type. -- ________________________________________________________ This .signature intentionally left blank ________________________________________________________
news@PSG.COM (Randy Bush) (01/31/91)
>> ..!{uunet,qiclab,intelhf,bucket}!m2xenix!news > ^^^^^^^^^^^^????? > And who is this masked-man slandering the good folks in the BSI group? ;-) I'm not hiding. My name is in the header of the articles. Signatures are just for folk who can't send mail to domain addresses, and must bang through. Yes, many newbies get carried away and put their family history down there. The best signature I have seen was "My header is my signature." randy
eepjm@cc.newcastle.edu.au (02/01/91)
In article <1991Jan30.091656.4348@mack.uit.no>, torbjorn@forit.forut.no (Torbjorn Sund) writes: > Who says that an opaque type is assignment or storage equivalent to ADDRESS? > At least one compiler (FTL) did not impose the restriction that an > opaque type be implemented as a pointer. Hear, hear! I use the FTL compiler a lot, and one of the things I like about it is that it implements opaque types "properly". Those compilers which insist that TSIZE(OpaqueType) <= TSIZE(ADDRESS) are, IMAO, next to useless. Why? (a) opaque types are very important in allowing a "clean" programming style (i.e. information hiding is important, and the language should allow it), and (b) more often than not, the "natural" implementation of an opaque type turns out to be a record, or something else which takes up a moderate amount of storage. Most compilers for Modula-2 force you to implement an opaque type as a pointer to the type which you really wanted, which means that the implementation code contains lots of pointer operations which in principle did not need to be there and which render the implementation code, in some cases, as clear as mud. (True, I use pointers a lot and find them useful, just as GOTO was very useful back in the days where I had to use Fortran - but both pointers and GOTOs are makeshift solutions which are forced upon us by language limitations, and should not be needed in a reasonable high-level language.) There is one little catch in the solution used by the FTL compiler to allow unrestricted opaque types: when it compiles an implementation module and discovers what the opaque type really is, it has to go back and modify the symbol file (i.e. the thing which was created when the definition module was compiled). This causes problems in working out inter-module dependencies (i.e. in working out which object modules are out of date), and may be one of the reasons why the "make" facility supplied with the FTL compiler keeps crashing. Crazy things can also happen when the definition module and the implementation module are in different directories. These are just compiler bugs which will presumably be fixed in some future version, but they do illustrate the hidden traps which a compiler-writer faces when trying to do the right thing about opaque types. At least one other compiler - sorry, I've forgotten its name - has an ingenious solution: it implements opaque types as pointers, but does not require the user to know about this. That is, it allows anything as an opaque type, and then inserts extra indirection, which is not visible to the programmer, as needed for its own convenience. Peter Moylan eepjm@cc.newcastle.edu.au