Mrthdrb

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 vice 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.

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.

I dislike answering my own questions. To that end, I have accepted the answer that is supported by the most historical sources. (Retrocomputing is about actual history, after all.) However, I'm not yet satisfied that the other answers completely answer the question.

Dennis Ritchie, the creator of the C language and co-creator of Unix, presented a history of C at an ACM conference in April 1993. The conference proceeding is available online as The Development of the C Language, and is quoted below.

C evolved from the short-lived B language, which in turn derived from BCPL. These two prior languages were typeless. All variables were word-sized values, which could represent signed integers, unsigned integers, characters, or pointers. Pointers could be used to reference the elements of arrays, strings, or data structures. The type that a word represented depended on the operators being used on it. As Ritchie noted,

Both languages are typeless, or rather have a single data type, the 'word,' or 'cell,' a fixed-length bit pattern. Memory in these languages consists of a linear array of such cells, and the meaning of the contents of a cell depends on the operation applied. The + operator, for example, simply adds its operands using the machine's integer add instruction, and the other arithmetic operations are equally unconscious of the actual meaning of their operands.

Ritchie's paper goes in depth about how the syntax for arrays developed. In BCPL, memory was accessed with the syntax pointer!offset. B changed memory access to a unary prefix operator *. Arrays could then be accessed with the expression *(array+offset). To "sweeten such array accesses", Ritchie added the now-familiar syntax array[offset] to B.

Structures didn't exist in BCPL or B; they were introduced in C. Ritchie doesn't discuss the history of structures as much as he does arrays. However, it does seem that early versions of C continued the practice that the meaning of a value was determined by the operators that used it. Ritchie notes:

Beguiled by the example of PL/I, early C did not tie structure pointers firmly to the structures they pointed to, and permitted programmers to write pointer->member almost without regard to the type of pointer; such an expression was taken uncritically as a reference to a region of memory designated by the pointer, while the member name specified only an offset and a type.

and

Compilers in 1977, and even well after, did not complain about usages such as assigning between integers and pointers or using objects of the wrong type to refer to structure members.

He doesn't explicitly explain the origins of . and ->, but it is reasonable to conclude that their purpose was to simplify expressions (much like [] did for arrays). As many have noted, pointer->member is a shorter way to write *(pointer+member). Similarly, variable.member is a shorter way to write *(&variable + member).

The critical thing here is that these two operations are not the same. Considering that embryonic C continued the tradition of leaving the determination of type to operators, two different operators were therefore needed. Embryonic C was not sophisticated enough to "know" the type of operands.

As C matured, later compilers would have enough information to make the distinction. However, Ritchie notes the importance of backward-compatibility for existing code, even as the language was evolving:

As should be clear from the history above, C evolved from typeless languages. It did not suddenly appear to its earliest users and developers as an entirely new language with its own rules; instead we continually had to adapt existing programs as the language developed, and make allowance for an existing body of code.

Just an aside: If the operator '*' were suffix not prefix, it would be neater; it would be yet neater if the suffixed reference-following operator were actually '.', as, I believe, it was in a language whereon C was based. In C p->f is sugar for (*p).f, but with suffix operator the sugar would be useless: p*.f or p..f . Years ago this was noticed, by whom I know not. I feel that one would be less tempted to wish '->' away.