Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!haven!uvaarpa!mcnc!rti!sheol!throopw
From: throopw@sheol.UUCP (Wayne Throop)
Newsgroups: comp.lang.c
Subject: Re: ptrs and arrays
Message-ID: <0174@sheol.UUCP>
Date: 10 Nov 89 17:58:09 GMT
References: <2640@dogie.macc.wisc.edu> <63332@psuecl.bitnet> <20527@mimsy.umd.edu> <0156@sheol.UUCP> <20671@mimsy.umd.edu>
Lines: 32

> chris@mimsy.umd.edu (Chris Torek)
> But look at what you just said: operations on the *element type* of the
> array: not operations on the array as a whole.  Operations on these
> elements need pointers to the elements, not a pointer to the array.

Yes.  But the manipulations are hidden inside procedures or macros.
The manufacture of the address of the entity to be manipulated might
also be encapsulated, but if the "&" unary operator is to be used in
any reasonable way (which is what I meant by *partial* information
hiding... the addressability is not abstracted), then one must be
able to utter the type of the resulting expression, so that it can
(for example) properly be passed to routines which will manipulate
it (and which know the correct size).

I admit that there are ways of avoiding this problem.  For example,
encapsulating the address-of operation, and having it yeild void or
pointer-to-element-type.  For another, have the interface specify
a pointer-to-void in a prototype, so that a cast will occur automagically.

I admit this as I say... But I also think it would be cleaner to be
able to simply utter the "correct" type.  Marginally cleaner, but
cleaner nonetheless.  (Or maybe it IS "theless", but it's *still*
cleaner notwhithstanding.)      (or should that be irregardless....)

Just think of how often people wish the jmp_buf type were cleaner
in just this sort of way.


> Arrays often get short shrift in C, and I think this applies to information
> hiding as well.

Very definitely agreed.  And we all know how painful *that* can be.
--
Wayne Throop <backbone>!mcnc!rti!sheol!throopw or sheol!throopw@rti.rti.org