Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!ucsd!ames!mailrus!uwmcsd1!marque!uunet!mcvax!unido!sbsvax!greim From: greim@sbsvax.UUCP (Michael Greim) Newsgroups: comp.unix.questions Subject: Re: why p->member ? Summary: my 2 cents worth Message-ID: <593@sbsvax.UUCP> Date: 11 Aug 88 11:16:40 GMT References: <16734@adm.ARPA> <23231@labrea.Stanford.EDU> <474@sp7040.UUCP> <3810@okstate.UUCP> <8097@alice.UUCP> <1355@ark.cs.vu.nl> Organization: Universitaet des Saarlandes, Saarbruecken, West Germany Lines: 70 In article <16734@adm.ARPA>, stanonik@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@sbsvax.UUCP | Universitaet des Saarlandes | | CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS) | | ARPA: greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15 | | Phone: +49 681 302 2434 | D-6600 Saarbruecken 11, West Germany | +------------------------------------------------------------------------------+ | # include| +------------------------------------------------------------------------------+