PATTIS@WARD.CS.WASHINGTON.EDU (Richard Pattis) (10/24/86)
Vincent Manis misunderstands what I want. I realize that for various reasons one cannot allow opaque types to be represented by arbitrarily large structures like arrays and records. In fact, when I teach array implementations of Tables I do it exactly as he says, with a pointer. It is the "cursor" opaque type that I am worried about; here I would like exactly what he describes - opaque types that are as big as the biggest "one-word" entity. I don't believe that this would be too wasteful of storage. Rich -------
chris@umcp-cs.UUCP (Chris Torek) (10/29/86)
In article <12249380101.10.PATTIS@WARD.CS.WASHINGTON.EDU> PATTIS@WARD.CS.WASHINGTON.EDU (Richard Pattis) writes: >... here I would like exactly what he describes - opaque types that are >as big as the biggest "one-word" entity. I missed the original discussion-cum-misunderstanding, but I cannot see the problem. In C, a language that has no direct support for opaque types, one creates them by using a `generic pointer' type. It is not hard to create a union (`variant record' for Pascal folks) containing both a generic pointer and a `one word entity' (for which C uses the word `int', as in integer: primitive perhaps, but quite workable). Indeed, I recently created just such a data structure: struct glyph { ... /* boring implementation stuff */ union { /* here comes the dirty part */ caddr_t un_pointer; /* generic pointer */ int un_word; /* word version */ } g_un; ... /* more boring stuff */ }; Clients of the glyph data structure can then either allocate their own data objects: g->g_un.un_pointer = new_object(); or, if they have a value that they know can be represented in one word, store it directly: g->g_un.un_word = integer_expression(); In a language with proper support for opaque types, a good compiler should automatically discover that a client's supplied type fits within the pointer word, and not bother allocating new objects. Since the pointer word can be manipulated only by the routines dealing with the specific object, there should never be any problem with this. (The supplier of the opaque type cannot assume that it always holds an allocated object. It must instead call the client's freeing routine to release these objects. This, however, is just another implementation detail.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu