Tjyylli

In the C programming language, the syntax to access the member of a structure is

structure.member

However, a member of a structure referenced by a pointer is written as

pointer->member

There's really no need for two different operators. The compiler knows the type of the left-hand value; if it is a structure, the first meaning is evident. If it is a pointer, the second meaning is evident. Furthermore, . is far easier to type than ->. Not only does -> have more characters to type, on many keyboards one character is unshifted and the other character is shifted, requiring some finger acrobatics. Indeed, many languages based on C allow or use . in place of ->.

Why did C use two operators when one would have sufficed?

(My guess would be because C evolved from the typeless B language.)

In the embryonic form of C described in the 1974 C Reference Manual, there was no requirement that the left operand of . actually be a structure, nor that the left operand of -> actually be a pointer. The -> operator meant "interpret the value of the left operand as a pointer, add the offset associated with the indicated structure member name, and dereference the resulting pointer as an object of the appropriate type. The . operator effectively took the address of the left operand and then applied ->.

Thus, given:

struct q { int x, y; };

int a[2];

the expressions a[0].y and a[0]->y would be interpreted in a fashion equivalent to ((struct q*)&a[0])->y and ((struct q*)a[0])->y, respectively.

If the compiler had examined the type of the left operand to the . operator, it could have used that to select between the two behaviors for it. It was probably easier, however, to have two operators whose behaviors didn't depend upon the left operand's type.

Despite your assertion, there would in fact be situations where it would be ambigious.

First off, early C compilers were very simple. This was in fact the main appeal of the language, as compilers for it were very easy to create and could run on very small systems, like early 16/32 microprocessors.

Adding a bunch of code for hitting all the niche cases of type inference would have drastically added to the amount of code required to make a C compiler. In fact, I've argued as a (half) joke that K&R C had type inference, but it always inferred int. If you didn't tell C what type an object was, it assumed int (which could cause some really gnarly bugs, let me tell you...)

Secondly, since K&R C was weakly(barely) typed, the information in many cases flat out wasn't available. The destination type of a pointer assignment can be an int, or visa versa, and K&R C has no problem with that. The compiler simply cannot infer a dereference. The coder is assumed to know what she's doing.

Also realize that in C pointers and arrays are essentially syntactic sugar for each other. This means now your . operator would have to automagically work on arrays too. For instance, if member happened to be a char array, now structure.member would return with the first character. And again, both chars and pointer are assignable into ints, so context doesn't help you.

This being said, you aren't the first to notice this issue. In fact, Ada was designed that dereferencing a pointer object is always assumed when a dot is used. In those cases where you want the actual pointer, you have to use .all. The ambiguity (pointer vs. pointed to object) is still there, but resolved by moving the extra syntax to the weirder case.

Some of the first C code I saw was like this: 0x8040->output = 'A'; — its purpose was accessing memory mapped I/O locations.  Needless to say it took me a while to figure out what this code was supposed to do, and the hex constant there really threw me.

The original K&R C placed all field names (here output) into the same namespace.  It was an error to have two fields of the same name in different structs at different offsets — but ok to have the same name at the same offset, the idea here being that two different structs could share the same initial fields, giving cheap way of doing "subclassing" to put varying data members at the end of the struct.

A struct could also be anonymous, e.g. no tag name for the struct.  None the less, the members could still be used in . or -> expressions.

The C Programming Language (K&R C) Appendix A, p197,209

[8.5] ... Two structures may share a common initial sequence of members; that is, the same member may appear in two different structures if it has the same type in both and if all previous members are the same in both.  (Actually, the compiler checks only that a name in two different structures has the same type and offset in both, but if the preceding members differ the construction is nonportable.)

...

[14.1] ... §7.1 says that in a direct or indirect structure reference (with . or ->) the name on the right must be a member of the structure named or pointed to by the expression on the left.  To allow an escape from the typing rules, this restriction is not firmly enforced by the compiler.  In fact, any lvalue is allowed before ., and the lvalue is then assumed to have the form of the structure of which the name on the right is a member.  Also, the expression before a -> is required only to be a pointer or an integer.  If an integer, it is taken to be the absolute address, in machine storage units, of the appropriate structure.

Since the K&R language & compiler didn't care what the type of the left hand side of . and -> was, the only way it had to tell the difference by having the two operators.

The ANSI C line of standards simply followed suit in syntax, even as these old rules were abandoned.

I think there are two factors that led to standardization of the distinct operator "->" for accessing data members using a pointer.

1. You assume that the C compiler would recognize the type of the LHS as being a pointer. But programmers could, and often did, override the initial typing (variable declaration) by using a typecast.


2. In order to make the code more readable and less prone to unintended side-effects, it is useful to distinguish operations using pointers.

A very common feature of idiomatic C code is that a structure passed to a function as a pointer is modified within the function. Thus, the result is returned implicitly, by the side-effect of the structure variable in the calling function having been modified by the callee. This sort of approach violates modern sensibilities about loosely coupled code, but it was a simple and efficient means of dealing with complexity in C code. I would say the programmer was greatly assisted in maintaining the readability of such code by having distinct operations that made it clear whether some (possibly shared) memory pointer was the thing whose target was being modified.