StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
13366168
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
11
CommunityOwnedDate
2012-11-22T21:42:07.330
CreationDate
2012-11-13T18:04:10.137
FavoriteCount
0
LastActivityDate
2017-02-03T16:32:54.180
LastEditDate
2017-02-03T16:32:54.180
LastEditorUserId
4325513
OwnerUserId
187690
ParentId
13366083
PostTypeId
2
Score
307
ViewCount
0
LastEditorDisplayName
text
Body
I'll interpret your question as two questions: 1) why <code>-></code> even exists, and 2) why <code>.</code> does not automatically dereference the pointer. Answers to both questions have historical roots. Why does <code>-></code> even exist? In one of the very first versions of C language (which I will refer as CRM for "<a href="https://www.bell-labs.com/usr/dmr/www/cman.pdf" rel="noreferrer">C Reference Manual</a>", which came with 6th Edition Unix in May 1975), operator <code>-></code> had very exclusive meaning, not synonymous with <code>*</code> and <code>.</code> combination The C language described by CRM was very different from the modern C in many respects. In CRM struct members implemented the global concept of byte offset, which could be added to any address value with no type restrictions. I.e. all names of all struct members had independent global meaning (and, therefore, had to be unique). For example you could declare <pre><code>struct S { int a; int b; }; </code></pre> and name <code>a</code> would stand for offset 0, while name <code>b</code> would stand for offset 2 (assuming <code>int</code> type of size 2 and no padding). The language required all members of all structs in the translation unit either have unique names or stand for the same offset value. E.g. in the same translation unit you could additionally declare <pre><code>struct X { int a; int x; }; </code></pre> and that would be OK, since the name <code>a</code> would consistently stand for offset 0. But this additional declaration <pre><code>struct Y { int b; int a; }; </code></pre> would be formally invalid, since it attempted to "redefine" <code>a</code> as offset 2 and <code>b</code> as offset 0. And this is where the <code>-></code> operator comes in. Since every struct member name had its own self-sufficient global meaning, the language supported expressions like these <pre><code>int i = 5; i->b = 42; /* Write 42 into `int` at address 7 */ 100->a = 0; /* Write 0 into `int` at address 100 */ </code></pre> The first assignment was interpreted by the compiler as "take address <code>5</code>, add offset <code>2</code> to it and assign <code>42</code> to the <code>int</code> value at the resultant address". I.e. the above would assign <code>42</code> to <code>int</code> value at address <code>7</code>. Note that this use of <code>-></code> did not care about the type of the expression on the left-hand side. The left hand side was interpreted as an rvalue numerical address (be it a pointer or an integer). This sort of trickery was not possible with <code>*</code> and <code>.</code> combination. You could not do <pre><code>(*i).b = 42; </code></pre> since <code>*i</code> is already an invalid expression. The <code>*</code> operator, since it is separate from <code>.</code>, imposes more strict type requirements on its operand. To provide a capability to work around this limitation CRM introduced the <code>-></code> operator, which is independent from the type of the left-hand operand. As Keith noted in the comments, this difference between <code>-></code> and <code>*</code>+<code>.</code> combination is what CRM is referring to as "relaxation of the requirement" in 7.1.8: Except for the relaxation of the requirement that <code>E1</code> be of pointer type, the expression <code>E1−>MOS</code> is exactly equivalent to <code>(*E1).MOS</code> Later, in K&R C many features originally described in CRM were significantly reworked. The idea of "struct member as global offset identifier" was completely removed. And the functionality of <code>-></code> operator became fully identical to the functionality of <code>*</code> and <code>.</code> combination. Why can't <code>.</code> dereference the pointer automatically? Again, in CRM version of the language the left operand of the <code>.</code> operator was required to be an lvalue. That was the only requirement imposed on that operand (and that's what made it different from <code>-></code>, as explained above). Note that CRM did not require the left operand of <code>.</code> to have a struct type. It just required it to be an lvalue, any lvalue. This means that in CRM version of C you could write code like this <pre><code>struct S { int a, b; }; struct T { float x, y, z; }; struct T c; c.b = 55; </code></pre> In this case the compiler would write <code>55</code> into an <code>int</code> value positioned at byte-offset 2 in the continuous memory block known as <code>c</code>, even though type <code>struct T</code> had no field named <code>b</code>. The compiler would not care about the actual type of <code>c</code> at all. All it cared about is that <code>c</code> was an lvalue: some sort of writable memory block. Now note that if you did this <pre><code>S *s; ... s.b = 42; </code></pre> the code would be considered valid (since <code>s</code> is also an lvalue) and the compiler would simply attempt to write data into the pointer <code>s</code> itself, at byte-offset 2. Needless to say, things like this could easily result in memory overrun, but the language did not concern itself with such matters. I.e. in that version of the language your proposed idea about overloading operator <code>.</code> for pointer types would not work: operator <code>.</code> already had very specific meaning when used with pointers (with lvalue pointers or with any lvalues at all). It was very weird functionality, no doubt. But it was there at the time. Of course, this weird functionality is not a very strong reason against introducing overloaded <code>.</code> operator for pointers (as you suggested) in the reworked version of C - K&R C. But it hasn't been done. Maybe at that time there was some legacy code written in CRM version of C that had to be supported. (The URL for the 1975 C Reference Manual may not be stable. Another copy, possibly with some subtle differences, is <a href="https://www.student.cs.uwaterloo.ca/~cs136/resources/cman.pdf" rel="noreferrer">here</a>.)
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POWhy does the arrow (->) operator in C exist?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USAnT
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POWhy does the arrow (->) operator in C exist?
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.