Opaque Types: A Misunderstanding

[Richard Pattis]

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 Torek]

In article <1224938010...@WARD.CS.WASHINGTON.EDU>
PAT...@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: ch...@mimsy.umd.edu