why p->member ?

Michael Greim greim at sbsvax.UUCP
Thu Aug 11 21:16:40 AEST 1988


In article <16734 at adm.ARPA>, stanonik at nprdc.arpa (Ron Stanonik) writes:
>While explaining pointers to structures someone asked why
>the -> operator was needed; ie, why couldn't the members be
>referenced as p.member.  My first response was, we're talking
>about pointers to structures, not structures, so a separate
>operator is needed.  On second thought though, since the
>compiler knows whether the variable is a pointer or structure,
>why shouldn't the compiler do the "right" thing when it sees
>p.member?
>
>Could this ever be ambiguous?  That is, is there some declaration
>of p such that p could be interpreted as both a structure and
>a pointer to a separate structure.  I tried fiddling around
>with unions, but could not produce such an object.
Yes, there is something which the compiler cannot decide.
Suppose you have a function
	a (s)
	struct some_struct s;
and you want to call it. So you say
	struct some_struct * s;
	...
	a (s);

What should the compiler do? Do you want the pointer by itself or
do you want to pass the structure s is pointing to?
In a the compiler must know what the parameters will be like.
It will have problems if the declaration of a is not in the same file
as the call.

Or suppose you do
	struct some_struct * s;
	...
	p = &s;
Do you want the address of s or of the structure s is pointing at ?

Or course one could devise some clever algorithm which elaborates on
"if a pointer happens to come along in a function call then
create and pass a record which holds a flag, so that the called function can
tell looking at its parameters what it really has been called with and
convert and copy the real actual parameter accordingly."
(If you are running VMS you get those nifty descriptors by which
a called function really sees what is passed. Or so the theory seems
to go. Overhead, if you ask me. In each program I write under VMS I
stumble across some case where I have to outwit this mechanism.
I would not be anstonished to hear that in VMS C the actual parameters
are passed as descriptors pointing at descriptors pointing at ...  :-)

But such a concept is
- difficult to remember : what do you expect, how often will you
	be wondering : "is the compiler really doing what I think it is ?"
	(Also called the "I wanted this ADA program to count to 10 and now
	it is sending my filled out tax forms to 20.000  people ???"-syndrom :-)
- confusing : it makes one confuse pointers with structures. And sometimes
	you need to understand the differences to know what the program does.
- generating difficulties in the compiler
- making programs more difficult to understand

To conclude : it might be possible, but what would it be worth?

	-mg
-- 
+------------------------------------------------------------------------------+
| UUCP:  ...!uunet!unido!sbsvax!greim   | Michael T. Greim                     |
|        or greim at sbsvax.UUCP           | Universitaet des Saarlandes          |
| CSNET: greim%sbsvax.uucp at Germany.CSnet| FB 10 - Informatik (Dept. of CS)     |
| ARPA:  greim%sbsvax.uucp at uunet.UU.NET | Bau 36, Im Stadtwald 15              |
| Phone: +49 681 302 2434               | D-6600 Saarbruecken 11, West Germany |
+------------------------------------------------------------------------------+
| # include <disclaimers/std.h>                                                |
+------------------------------------------------------------------------------+



More information about the Comp.unix.questions mailing list