I'm just now learning about C.

I find it odd that the creators chose the asterisk (*) as the symbol for pointers rather than a symbol that actually looks like a pointer (->).

Considering how confusing dereferencing and function pointers can be, is there a historical, or even practical, reason for using the asterisk?

closed as primarily opinion-based by Jimmy Hoffa, durron597, Ixrec, user40980, Robert Harvey Oct 12 '15 at 5:39

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 10
    Note that -> is being used in the C language as a dereference operator – when accessing fields in a struct: struct_pointer->field, which is short for (*struct_pointer).field. – amon Aug 1 '14 at 22:19
  • @amon: It only applies to structs for dereferencing, which seemed odd to me. It's a pointer symbol, right? Why not (<-) for dereferencing? Am i really the only one that thinks this way? – Noob Saibot Aug 1 '14 at 22:25
  • 1
    Given the two excellent answers in this question, including one with an answer directly from the language designer, it's hard to really justify the close as "opinion-based". I've therefore nominated for reopening. – Jules Jun 3 '16 at 7:18
  • IMHO Pascal style is better. ^ is used and can be thought of a rotated arrow and read as "point to", same meaning as -> but shorter. ^integer means "pointer to integer" for type declaration, and var^ means "the memory var points to" for dereferencing. The symbol position is more logical than C when reading from left to right, which always put after type and before variable name. Pascal also uses @ for taking address, which is better than &, because @var is "the address at which var is located" – phuclv Apr 14 at 15:27
up vote 57 down vote accepted

Why does C use the asterisk for pointers?

Simply - because B did.

Because memory is a linear array, it is possible to interpret the value in a cell as an index in this array, and BCPL supplies an operator for this purpose. In the original language it was spelled rv, and later !, while B uses the unary *. Thus, if p is a cell containing the index of (or address of), or pointer to) another cell, *p refers to the contents of the pointed-to cell, either as a value in an expression or as the target of an assignment.

From The Development of the C Language

Thats it. At this point, the question is as uninteresting as "why does python 3 use . to call a method? Why not ->?" Well... because Python 2 uses . to call a method.

Rarely does a language exist from nothing. It has influences and is based on something that came before.


So, why didn't B use ! for derefrencing a pointer like its predecessor BCPL did?

Well, BCPL was a bit wordy. Instead of && or || BCPL used logand and logor. This was because most keyboards din't have or keys and not equal was actually the word NEQV (see The BCPL Reference Manual).

B appears to have been partially inspired to tighten up the syntax rather than have long words for all these logical operators that programmers did fairly frequently. And thus ! for dereference became * so that ! could be used for logical negation. Note there's a difference between the unary * operator and the binary * operator (multiplication).


Well, what about other options, like ->?

The -> was taken for syntactic sugar around field derefrences struct_pointer->field which is (*struct_pointer).field

Other options like <- could create ambiguous parsings. For example:

 foo <- bar

Is that to be read as:

(foo) <- (bar)

or

(foo) < (-bar)

Making a unary operator that is composed of a binary operator and another unary operator is quite likely to have problems as the second unary operator may be a prefix for another expression.

Furthermore, it is again important to try to keep the things being typed frequently to a minimum. I would hate to have to write:

int main(int argc, char->-> argv, char->-> envp)

This also becomes difficult to read.

Other characters might have been possible (the @ wasn't used until Objective C appropriated it). Though again, this goes to the core of 'C uses * because B did'. Why didn't B use @? Well, B didn't use all the characters. There was no bpp program (compare cpp) and other characters were available in B (such as # which was later used by cpp).

If I may hazard a guess as to why - its because of where the keys are. From a manual on B:

To facilitate manipulation of addresses when it seems advisable, B provides two unary address operators, * and &. & is the address operator so &x is the address of x, assuming it has one. * is the indirection operator; *x means "use the content of x as an address."

Note that & is shift-7 and * is shift-8. Their proximity to each other may have been a hint to the programmer as to what they do... but that's only a guess. One would have to ask Ken Thompson about why that choice was made.


So, there you have it. C is that way because B was. B is that way because it wanted to change from how BCPL was.

  • 2
    ...awesome! This is a great answer, @MichaelT! You showed me both historical and practical reasons, and even stuff I didn't quite understand but could look into. Thank you. +1 – Noob Saibot Aug 2 '14 at 2:09
  • @NoobSaibot The choice of character isn't as much of a deal as the fact that the operator is a prepend rather than postpend operator. This necessitates lots of extra parens (though the -> syntactic sugar helps) which can lead to silly yet vexing bugs even for an experienced C++ programmer. – Trixie Wolf Aug 2 '14 at 3:48
  • 1
    You might also mention that C found a use for almost every Ascii punctuation character. There weren't many spares. I guess @ would have been another possibility. – david.pfx Aug 2 '14 at 15:00
  • 1
    @david.pfx I've expanded on that - though it wasn't C that made that choice... it was B. And, well, I made a guess as to why (keyboard proximity of & and *). B also didn't use # so there were a few more spares around then... there's also $. – user40980 Aug 2 '14 at 17:18
  • 1
    @david.pfx The B tutorial that I found was written by B. W. Kernighan. Unfortunately, Dennis Ritchie is no longer able to be asked (he passed away in October of '11) while Kernighan is apparently still a professor in the CS Department at Princeton. Ken Thompson (the other creator of B) works at Google... There may also have been issue with some keyboards (indicated by the trigraphs for C for what we would think of as common keys) suggesting that not all of them were available (I'm not sure if '@' was). – user40980 Aug 3 '14 at 1:30

I was asked by a student if & and * were chosen because they were next to each other on the keyboard (something I had never noticed before). Much googling led me to B and BCPL documentation, and this thread. However, I couldn't find much at all. It seemed like there were lots of reasons for * in B, but I couldn't find anything for &.

So following @MichaelT's suggestion, I asked Ken Thompson:

From: Ken Thompson < ken@google.com >

near on the keyboard: no.
c copied from b so & and * are same there.
b got * from earlier languages - some assembly,
bcpl and i think pl/1.
i think that i used & because the name (ampersand)
sounds like "address." b was designed to be run with
a teletype model 33 teletype. (5 bit baud-o code)
so the use of symbols was restricted.

  • 18
    +1 for contacting Ken Thompson and reporting back here. – stakx Feb 15 '15 at 9:55

Not the answer you're looking for? Browse other questions tagged or ask your own question.