Why is the dereference operator (*) also used to declare a pointer?

In The Development of the C Language Dennis Ritchie explains his reasoning thusly.

In The Development of the C Language, Dennis Ritchie explains his reasoning thusly: The second innovation that most clearly distinguishes C from its predecessors is this fuller type structure and especially its expression in the syntax of declarations... given an object of any type, it should be possible to describe a new object that gathers several into an array, yields it from a function, or is a pointer to it.... This led to a declaration syntax for names mirroring that of the expression syntax in which the names typically appear. Thus, int i, *pi, **ppi; declare an integer, a pointer to an integer, a pointer to a pointer to an integer. The syntax of these declarations reflects the observation that i, *pi, and **ppi all yield an int type when used in an expression.

Similarly, int f(), *f(), (*f)(); declare a function returning an integer, a function returning a pointer to an integer, a pointer to a function returning an integer. Int *api10, (*pai)10; declare an array of pointers to integers, and a pointer to an array of integers. In all these cases the declaration of a variable resembles its usage in an expression whose type is the one named at the head of the declaration.An accident of syntax contributed to the perceived complexity of the language.

The indirection operator, spelled * in C, is syntactically a unary prefix operator, just as in BCPL and B. This works well in simple expressions, but in more complex cases, parentheses are required to direct the parsing. For example, to distinguish indirection through the value returned by a function from calling a function designated by a pointer, one writes *fp() and (*pf)() respectively.

The style used in expressions carries through to declarations, so the names might be declared int *fp(); int (*pf)(); In more ornate but still realistic cases, things become worse: int *(*pfp)(); is a pointer to a function returning a pointer to an integer. There are two effects occurring. Most important, C has a relatively rich set of ways of describing types (compared, say, with Pascal).

Declarations in languages as expressive as C—Algol 68, for example—describe objects equally hard to understand, simply because the objects themselves are complex. A second effect owes to details of the syntax. Declarations in C must be read in an `inside-out' style that many find difficult to grasp.

Sethi Sethi 81 observed that many of the nested declarations and expressions would become simpler if the indirection operator had been taken as a postfix operator instead of prefix, but by then it was too late to change.

1 +1 for a helpful reference – Stuart Golodetz Dec 31 '11 at 1:10 4 @diggingforfire: And I wish you'd used full stops there rather than commas :( – Lightness Races in Orbit Dec 31 '11 at 1:59 1 @diggingforfire You may also like my "graph paper and pencil" technique for reasoning with pointers (example: stackoverflow.com/questions/7062853/…). I generally believe that learning what the machine actually does with pointers first makes learning the C abstraction easier; rather than trying to learn the abstraction first and then the concrete after. – Crashworks Dec 31 '11 at 2:38 1 What part of this quote explains why prefix * was selected over alternatives?

– David Heffernan Dec 31 '11 at 8:29 1 @DavidHeffernan - the "just as in BCPL and B" in BCPL all unary operators were prefix – Mark Dec 31 '11 at 15:06.

The reason is clearer if you write it like this: int x, *y; That is, both x and *y are ints. Thus y is an int *.

Actually, this is not clearer if you expand it. I don't want to start an argument, but I'd like to point out that this syntax is bound to lead to one. – Lightness Races in Orbit Dec 31 '11 at 1:02 1 I agree that you shouldn't use this syntax in practice - it was merely to illustrate the point (which is the same point David makes).

– Stuart Golodetz Dec 31 '11 at 1:03 Indeed, nothing against you or your answer (except perhaps the "clearer" part) – Lightness Races in Orbit Dec 31 '11 at 1:04 No offence taken :) Just trying to clarify. – Stuart Golodetz Dec 31 '11 at 1:05 3 Probably not the clearest answer in the world, but typed on an iPad hence shorter than normal. The point I was trying to make is that if you group the * with the variable name then it becomes clearer where this syntax came from - namely the idea that by saying * y is an int, you are implying that y itself is an int *.

As this answer has been borne out in practice by the reference given (and it wasn't a guess), I'm not sure where the hostility is coming from. Anyway, let's agree to disagree. – Stuart Golodetz Dec 31 '11 at 12:41.

That is a language decision that predates C++, as C++ inherited it from C. I once heard that the motivation was that the declaration and the use would be equivalent, that is, given a declaration int *p; the expression *p is of type int in the same way that with int i; the expression I is of type int.

Page 65 of Expert C Programming: Deep C Secrets includes the following: And then, there is the C philosophy that the declaration of an object should look like its use. Page 216 of The C Programming Language, 2nd edition (aka K&R) includes: A declarator is read as an assertion that when its identifier appears in an expression of the same form as the declarator, it yields an object of the specified type. I prefer the way van der Linden puts it.

Because the committee, and those that developed C++ in the decades before its standardisation, decided that * should retain its original three meanings: A pointer type The dereference operator Multiplication You're right to suggest that the multiple meanings of * (and, similarly, &) are confusing. I've been of the opinion for some years that it they are a significant barrier to understanding for language newcomers. Why not choose another symbol for C++?

Backwards-compatibility is the root cause... best to re-use existing symbols in a new context than to break C programs by translating previously-not-operators into new meanings. Why not choose another symbol for C? It's impossible to know for sure, but there are several arguments that can be — and have been — made.

Foremost is the idea that: when an identifier appears in an expression of the same form as the declarator, it yields an object of the specified type. {K&R, p216} This is also why C programmers tend tocitation needed prefer aligning their asterisks to the right rather than to the left, i.e. : int *ptr1; // roughly C-style int* ptr2; // roughly C++-style though both varieties are found in programs of both languages, varyingly.

3 I don't think the committee decided anything; it was probably Dennis Ritchie when he created C. – Brian Neal Dec 31 '11 at 1:07 The committee is responsible for the language we know today. Fair point, it started with DR, but that's not "C" as we know it now.

And, more than much else, the C++ committee has the conscious decision for the C++ language -- Ritchie did not. – Lightness Races in Orbit Dec 31 '11 at 1:07 7 Before there was a committee, Ritchie invented that syntax. Stroustrup was not going to break backwards compatibility with C by not using it.

All these decisions were made before the development of C and C++ was put under a standards body. – Brian Neal Dec 31 '11 at 1:14 1 @BrianNeal: Fine, but the languages as we know them are governed by those committees, and those committees are -- currently -- responsible for that decision. Unless you want to credit that first protein in the primordial soup.

– Lightness Races in Orbit Dec 31 '11 at 1:58.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.