Pointers and Arrays

Root Boy Jim rbj at icst-cmr
Thu Jul 24 03:13:16 AEST 1986


	> davidsen at steinmetz.UUCP (Davidsen)
	
	> Reason 2: "modularity and information hiding"
	
	Unfortunately this argument doesn't hold up, for two reasons.  First,
	&array (when it is allowed) currently most often evaluates to the
	address of the first element of the array, not to the address of the
	whole array.  Thus, you can't hide the array-ness anyhow, since this is
	different than other applications of the & operator.

Hopefully, the first element is at the same address as the entire array.
	
	Second, the inability to hide information ...

I pretty much agree, but then we're talking data type. I don't care
what I get back from localtime; I just want to pass it to ctime.
	
	> Reason 3: "common sense"
	> After five years of teaching C, I have to agree with my students that
	> it makes no sense to forbid this construct. To take the address of
	> something use the address operator.
	
	I have a great deal of sympathy for this view.  But NOTE WELL, that it
	should yield the address of the WHOLE ARRAY, and NOT the address of the
	first element of the array.  This is DIFFERENT than current usage.  Note
	that it would make
	
	        int actual[10];
	        void f(formal) int formal[10];{}
	        void g(){ f(&actual); }
	
	type-incorrect, since the formal is expecting type (int *), and gets
	type (int (*)[]) instead.

If you think about it, a pointer to an int can be used (and is) as a pointer
to an array of ints. Unless you apply ++ to it, they are the same thing.
(I can already feel the flames approaching).
	
	Also note that "to take the address of something, use the address
	operator" is overly simplistic, even if arrays could be "&"ed.  There
	are many "somethings" that cannot be "&"ed, such as register variables,
	bit fields, expressions, and so on.  Arrays happen currently to be one
	of these.
	
Taking a larger view, while I think that it's relatively harmless, except
for macros, there's no compelling reason to clamor for this either. On the
other hand, compilers should warn about but ignore the `&' as that's what
the guy probably meant anyhow, and he shouldn't have to recompile just for that.

	To sum up, I wouldn't be absolutely aghast if ANSI legislated that
	&array should work.  But NOTE WELL that it would constitute YASC, and it
	would be a crime against reason to make it work as it does in some
	compilers now, such that &array gives a conceptually different type than
	&non_array.  And, on balance, I'd say it isn't really that good an idea.

Yeah. Who cares?
	
	Wayne Throop      <the-known-world>!mcnc!rti-sel!dg_rtp!throopw

	(Root Boy) Jim Cottrell		<rbj at icst-cmr.arpa>
	I hope I bought the right relish...zzzzzzzzz..."
	



More information about the Comp.lang.c mailing list