<p>In C, when you declare an array of type <code>int</code> like so</p>
<pre><code>int n = 500;
int *a = malloc(n*sizeof(int));
</code></pre>
<p>the name <code>a</code> stores the heap memory address of a chunk of memory. When you use the sqaure-bracket operator as in <code>a[k]</code>, you &quot;go&quot; to address <code>a</code>.   Baked into the pointer data type is knowledge of the size of the type you have in your array; hence <code>a[k]</code> means that after you go to <code>a</code>, you move over <code>k</code> integer spaces.  Note that the compiler generates the same code for <code>a[k]</code> and <code>*(a + k)</code>.</p>
<p>A similar thing occurs if you allocate this memory on the stack.</p>
<p>Other languages have inherited this convention from C. One example that does not is R; it uses 1-based indexing. This is the explanation I give to my students, and they find it very reasonable.</p>

CC BY-SA 4.0
2021-05-31T11:29:09.713Z
Also note: the array's name is const; you cannot increment it.
ncmathsadist
CC BY-SA 4.0
2021-05-30T21:59:53.570Z
2021-05-30T21:59:53.570Z
ncmathsadist
<p>This was too long for a comment (Please view it as such)</p>
<ol>
<li><p><strong>Way-of-teaching-reference</strong>: I can recommend the way Jerry Cain (Stanford University) introduced the concepts in C in CS107 (Programming Paradigms) (available on iTunes-U).</p>
</li>
<li><p><strong>Problem mixing</strong>: I think you're mixing two problems:</p>
<ul>
<li>(a) C syntax is difficult</li>
<li>(b) pointer introduction<br><br>
So <code>does the introduction of pointers and memory complicate the process so much so that confusion about arrays will increase rather than decrease?</code> -&gt; I wouldn't say so. I would rather say &quot;introducing them in C might be counterproductive&quot;. <br><br>
Remember, that your <code>pointing finger</code> is also a pointer: It can point at a bridge without being the bridge. If it's in your pocket it points at nothing. Your finger can also point at a glass of water. If you close your eyes, you will not recognize, if someone takes away the glass. So assuming your finger always points at the glass can be &quot;dangerous&quot;. Someone might exchange it for spinach soup.</li>
</ul>
</li>
<li><p><strong>Nothing new</strong>: Pointers and arrays are a very common concept in the real world. I see many educators overcomplicating explanations. Here's a guy explaining pointers by paper in drawers: (Japanese audio) <a href="https://www.youtube.com/watch?v=qhquKBfPyDs" rel="nofollow noreferrer">https://www.youtube.com/watch?v=qhquKBfPyDs</a></p>
<ul>
<li>Every drawer has a paper saying &quot;chocolate&quot; (like the type in programming), where to find the next hint (pointer), and the information on how many hints are there to come (like the <code>*</code> in C).</li>
<li>He looks at all hints and finally finds the chocolate.</li>
</ul>
</li>
</ol>

CC BY-SA 4.0
2021-03-29T13:39:36.720Z
2021-05-26T11:30:03.250Z
2021-05-26T11:30:03.250Z
DarkTrick
<p>You overestimate the complexity of 0-based indexing a lot. <a href="//cseducators.stackexchange.com/a/231/216">There is nothing complex in 0-based indexing</a>.</p>
<p>On the other side, the topic of the pointers is relatively complex. I don't think it has any sense to introduce pointers earlier, than at the time when a pupil would be ready to fully feel their usefulness and use them in practice. Especially in languages like C, where the syntax of pointers is quite weird (I mean: it was a quite illogical decision for language creators to use the same syntax for arrays and pointers; as they actually have almost nothing in common: an array is usually a large-sized object containing one or more items of a specific type, a pointer is a tiny-sized object that doesn't contain even a single item, it contains only the address; pointers to items and <em>pointers to arrays</em> should have some convergence, but pointers to items and <em>arrays</em> — no more than, for example, a pointer to the item of a specified type and <em>a structure whose first member is of specified type</em>).</p>

CC BY-SA 4.0
2018-05-30T07:15:15.137Z
Pointers are (unfortunately for beginners) a must-have in early stage of C teaching, as you certainly want the students to use a procedural approach for programming (decomposition of actions as small functions, thus transmitting parameters by copy and by reference).
Michel Billaud
CC BY-SA 4.0
2018-05-30T12:40:59.783Z
@MichelBillaud, yes, I consider it a big downside of C. I personally started from Pascal and therefore, when being beginner, I had by-ref-parameters without pointers. Maybe it's better to start learning C without by-ref parameters (i.e. pass in by copy, pass out through result or through a member of result structure) in the beginning?
Sasha
CC BY-SA 4.0
2018-05-30T13:09:46.053Z
@Sasha Maybe it's better to learn the basics of programming with a more civilized language, and keep C for occasions where you really need low level stuff for efficiency (which drastically excludes transmitting copies of things when not necessary). C as a first language defeats its own purpose.
Michel Billaud
CC BY-SA 3.0
2017-05-27T18:50:37.633Z
I didn't refer to it as complex, just challenging. I don't think it is a difficult idea. Based on my experience with students in the classroom, the adjustment to starting at 0 "feels" different and odd at first. I'm just seeking ways of making it feel more intuitive by grounding it in real-life examples, hence the motivation for the other thread.
Peter
CC BY-SA 4.0
2017-05-27T13:37:06.623Z
2021-05-26T03:56:34.497Z
2021-05-26T03:56:34.497Z
Sasha
<p>This is a <em>great</em> explanation of why 0-indexing exists. As someone who barely knows what a pointer is, your explanation made perfect sense. If you wanted to dumb it down a little you could phrase it as:</p>

<blockquote>
  <p>When you create an array, the variable you assign that array to is actually a pointer to the first element. Lets create an array <code>num</code>. When you want to modify the array, to get a pointer to the first element you want to add 0 to <code>num</code>, because <code>num</code> points to the first element. For the second element, you add 1 to <code>num</code> because <code>num</code> is a pointer to the first element and the second is one after the first. Then for the third element, you add 2 to `num, and so on, so that the first is adding 0, the second is adding 1, and the third is adding 2.</p>
</blockquote>

<p>A useful resource is <a href="https://web.archive.org/web/20171112035729/https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html" rel="nofollow noreferrer">this website</a> which explains how <code>num[i]</code> is syntactic sugar for pointer arithmetic (<code>*(num+i)</code>).</p>

<p>I think that this discussion will increase clarity and be very useful because it makes sense as a logical way to implement arrays and revels a cool thing about the language. I'm not sure that you have to talk about memory, but talking about pointers is certainly worthwhile for this example.</p>

CC BY-SA 3.0
2017-05-27T18:32:30.210Z
Thanks for sharing that link. I'll use to supplement this lesson should I likely go this direction next year.
Peter
CC BY-SA 3.0
2017-05-27T18:34:44.580Z
@Peter Glad I could help. Because this is about AP CS Principles, I guess I should add that this is from the perspective of someone who is taking the class next year.
thesecretmaster
CC BY-SA 4.0
2017-05-27T11:17:12.100Z
2018-05-29T16:32:10.717Z
2018-05-29T16:32:10.717Z
thesecretmaster
<p><strong>Draw ongoing attention to the potentially confusing point by banning cardinal descriptions of an element's position.</strong></p>

<p>Avoid referring to the "first element" or "second element" and talk only about "element at index 0" or "at index 1." Insist that your students speak only of indices and not of position in a sequence. If you ever use cardinal numbers in human language, you might get it right ("the second element is the element at index 1") but beginners will stumble, as you point out. If you correct with a smile when a student speaks to refer to an element with cardinal numbers, the class will join you in "catching" cardinal language. While there's nothing wrong with cardinal language, a playful "ban" gives students the opportunity to think through the point of confusion every time someone speaks about an index.</p>

<p>Your question as to "does teaching pointer arithmetic reduce student mistakes related to 0-indexing" is an empirical question. I don't know, but I'm suggesting another treatment, the playful ban. My evidence is mere anecdotal experience that this works in my classroom with my teaching style. There does not exist, to my knowledge, any report in the CS ed literature comparing students in a class that "prohibits" cardinal description by friendly censors vs. a class that does no such thing. As CS educators, we have a long way to go before we can boast of a compendium of empirically derived pedagogical content knowledge. Physics has the tome I envy: a 4-pound 11-pt-font book summarizing peer-reviewed measurement of effects of classroom nuances like this. Please, CS ed, produce something akin to <a href="http://rads.stackoverflow.com/amzn/click/0471137073" rel="nofollow noreferrer"><em>Teaching Introductory Physics</em></a>. Guzdial's <a href="http://rads.stackoverflow.com/amzn/click/1627053514" rel="nofollow noreferrer"><em>Learner-centered Design of Computing Education</em></a> is a wonderful book, but we have a long way to go to match the physics education community's understanding of their craft. </p>

CC BY-SA 3.0
2017-07-03T15:52:50.587Z
@nocomprende then four-th and fourth would refer to a[4] and a[3]. Ditto for 6, 7, 8, ...
Bennett Brown
CC BY-SA 3.0
2017-08-07T01:24:32.913Z
@BennettBrown My [most recent question](https://cseducators.stackexchange.com/questions/3152/books-about-pedagogical-research-within-our-field) might interest you.  (And I'd be highly interested in your response)
Ben I.
CC BY-SA 3.0
2017-07-03T03:51:20.317Z
2017-07-03T15:50:53.547Z
2017-07-03T15:50:53.547Z
Bennett Brown
<p>I am not advocating teaching pointers to explain 0-indexing (see mine and other's answers on your other question for how to do that). However, if we have good reason to teach pointers, here is a tip that helped me when I was learning. I have also shared these ideas with other pupils, and they started to make progress.</p>
<p>I find code involving pointers confusing: is it a pointer, or is it the real thing. To help me with this I adopted a little bit of <a href="https://en.wikipedia.org/wiki/Hungarian_notation" rel="nofollow noreferrer">Hungarian notation</a> (I don't generality advocate Hungarian notation in strongly typed languages, but for pointers, it is a great help.</p>
<h2>Prerequisite</h2>
<p>It is important to ensure that all variables and routines have good names:</p>
<ul>
<li><p>Routines that do something (change something), should not return a value and should have a verb name (or verb phrase). (one style would allow returning of status, this is needed in non-object-oriented programming.)</p>
</li>
<li><p>Booleans should be adjectives (start with is, has was (no future tense).</p>
</li>
<li><p>Variables and routines returning a non-boolean value, should be a noun (or noun phrase).</p>
</li>
</ul>
<h2>The notation</h2>
<p>Append a <code>_pt</code> to the end of the name of all pointers.</p>
<h2>Explanation</h2>
<pre><code>int numberOfCats     /*  numberOfCats is an integer*/
int *numberOfDogs_pt /* *numberOfDogs_pt is an integer*/


numberOfCats  /*a real integer*/
&amp;numberOfCats /*a pointer to an integer*/

*numberOfDogs_pt /*a real integer, like what was declared*/
numberOfDogs_pt  /*a pointer, as in its name*/
</code></pre>
<p>If you see a <code>*???_pt</code> then you can cancel out the <code>*</code> and the <code>_pt</code>, it is in this context, not a pointer, but I can drop the <code>*</code> to make it a pointer. Where a variable does not have a <code>_pt</code>, there is no <code>*</code> to drop, however, I can add a <code>&amp;</code>. <code>&amp;</code> works as the opposite of a <code>*</code>.</p>
<p><code>*&amp;numberOfCats</code> is same as <code>numberOfCats</code></p>
<hr />
<p>Hope this is useful.</p>

CC BY-SA 4.0
2017-05-28T09:46:38.627Z
2021-05-28T15:40:24.843Z
2021-05-28T15:40:24.843Z
ctrl-alt-delor
<p>Let me suggest, pretty strongly, that you may be mixing up too many ideas in too short space for novices to grasp in one go. Spread it out. There is no real reason to <em>introduce</em> arrays along with pointers, nor to give a complex reason for zero indexing at the start. In C, you don't want to avoid it altogether, of course, but you don't dump the whole load at once.</p>
<h2>Step one</h2>
<p>I'd suggest that you first present arrays in a simple way, using all of the available sweeteners that there is (syntactic sugar). Something like <a href="https://www.tutorialspoint.com/cprogramming/c_arrays.htm" rel="nofollow noreferrer">this tutorial</a> is pretty clear. It enables the use of arrays for nearly all purposes.</p>
<p>You can describe an array as a &quot;contiguously stored block of values of the same type.&quot; One easy way to talk about zero indexing in this context is to think of the index as the <em>distance from the start</em>. If you aren't asked about what distance means at the start you can just ignore it, but if asked, you can talk, briefly, about each type has a &quot;size&quot; and the distance is measured in units of this size. Thus the &quot;first&quot; element is at distance 0, so has index 0.</p>
<h2>Step two</h2>
<p>Once arrays are solidly integrated into the students' thinking process you can introduce pointers in general, but not yet connected to arrays. Again, the <a href="https://www.tutorialspoint.com/cprogramming/c_pointers.htm" rel="nofollow noreferrer">Tutorials Point introduction</a> is pretty much at the level that is needed.</p>
<p>But you have introduced two concepts and the pedagogy was to keep them separate initially so that each can be learned on its own merits. Now you can merge the two ideas and will then deepen the understanding of both.</p>
<h2>Step three</h2>
<p>This <a href="https://www.tutorialspoint.com/cprogramming/c_pointer_to_an_array.htm" rel="nofollow noreferrer">third tutorial</a> explains it quite well. Note that since you used the &quot;distance&quot; metaphor for indexing initially it all comes together. In an array of doubles,</p>
<pre><code>double balance[5] = {1000.0, 2.0, 3.4, 17.0, 50.0};
</code></pre>
<p>the measurement is the size of a double. the compiler knows this so that in:</p>
<p>*(balance + 2) : 3.400000</p>
<p>adding 2 is sufficient since the compiler knows the measurement scale from the declaration. So the 2 means 2 units where a unit is <em>sizeof double</em>.</p>
<h2>Summary</h2>
<p>The key idea here is to teach the three topics separately in a way that enables use but also avoids requiring too many more-or-less independent ideas to be needed in any one discussion. In the third part (pointer to an array) you remind them of what they already know and show them an alternate way to think about things that can reinforce what they know (contiguous block of values of the same type + distance) and make it actually computational.</p>
<p>You can emphasize that both the &quot;contiguous&quot; part and the &quot;same type&quot; part are essential in this computation. This gives you a hook to discuss variations, say linked-list vs arrays or homogeneous vs heterogeneous structures.</p>

CC BY-SA 4.0
2018-05-29T12:27:27.657Z
2021-05-26T11:15:18.700Z
2021-05-26T11:15:18.700Z
Buffy
<p>One of the most challenging concepts to instill in new CS students is 0-indexing (indeed, <a href="https://cseducators.stackexchange.com/questions/213/real-life-examples-of-0-indexing">the pedagogy of this fact probably merits its own discussion</a>). Another difficult topic -- although a slightly more advanced one -- is pointers. (I'm thinking particularly of programming in C.) With this question I'm wondering if part of the difficulty is the syntactic sugar in C that allows the following to be equivalent:</p>
<pre><code>// declare array of 5 ints on the stack
int num[5];

// use array notation to change first element
num[0] = 42;

// use pointer arithmetic to change first element
*(num + 0) = 42;
</code></pre>
<p>With array notation, we are explicit with 0-indexing, but the logic of it isn't apparent. Yet, with pointer arithmetic, it's more clear (I think...) why we use 0: the pointer stores the base address, so dereferencing the pointer brings us to that address which is where the array logically begins.</p>
<p>Comfort with this leads to the topic of memory management on the heap with something like this:</p>
<pre><code>// declare array of 5 ints on the heap
int *num = malloc(sizeof(int) * 5);

// use pointer arithmetic to change first element
*num = 42;
</code></pre>
<p>I am toying with expanding my introduction on arrays next year to include this particular use of pointers. I recognize that it would involve taking roughly a single lesson on arrays and expanding to something closer to a week-long series to tie all of these ideas together.</p>
<p><strong>However, is it worth putting aside the syntactic sugar in order to understand more accurately the indexing of arrays? On the other hand, does the introduction of pointers and memory complicate the process so much so that confusion about arrays will increase rather than decrease?</strong> (I'm thinking this is a &quot;lesson idea feedback&quot; discussion.)</p>

CC BY-SA 3.0
2017-12-14T13:04:56.860Z
I know a handful of seasoned C programmers, who seeing `*(pointer + integer) = z` would instantly charge at you with any sharp and heavy object they can find. It is widely believed that doing arithmetic on pointers and integers is one of the worst intentional features of C. This was a motivation for creation of a lot of other languages, who'd proudly declare that, unlike in C, this kind of pointer arithmetic is prohibited.
wvxvw
CC BY-SA 3.0
2017-06-09T18:52:00.987Z
I agree with @Sasha that 0-based arrays are a little strange but pointers are much much more difficult. Better to not confuse things by combining the two until both concepts are consolidated in students' minds.
Rory
CC BY-SA 3.0
2017-07-03T03:54:17.017Z
https://www.quora.com/Why-do-array-indexes-start-with-0-zero-in-many-programming-languages describes multiple reasons for 0 indexing, including last_index - first_index should be length_of_array as well as your pointer argument.
Bennett Brown
CC BY-SA 3.0
2017-05-27T10:19:00.950Z
Hard to remember back this far, but the malloc example is useful even if you skip over the work underneath. It exposes the machinery inside the black box just enough.
Sean Houlihane
CC BY-SA 3.0
2017-05-27T10:34:51.010Z
Is this an AP CS class, or something where you have more free reign in the curriculum?  And what is the general language of the course?
Ben I.
CC BY-SA 3.0
2017-05-27T18:30:54.993Z
Yes, AP CS Principles, more specifically CS50 AP. The curriculum includes pointers in an optional unit, but my gut says to include it regardless. We spend about a week in Scratch for general programming concepts and then focus on C for the rest of the semester before also going over basic Python the second semester.
Peter
CC BY-SA 3.0
2017-05-28T09:19:37.160Z
Note: `sizeof(myarray)` gives the size of your array, (if I remember correctly) in bytes. Where as `sizeof(mypointer)` gives the size of a pointer (4 or 8, depending or architecture). Also arrays can-not be passed to another routine, only a pointer is passed.
ctrl-alt-delor
<lesson-ideas><arrays><c><syntax><abstraction>
Lesson Idea: Arrays, Pointers, and Syntactic Sugar
# Lesson Idea: Arrays, Pointers, and Syntactic Sugar

(Asked by: username_0 on 2017-05-27)

One of the most challenging concepts to instill in new CS students is 0-indexing (indeed, the pedagogy of this fact probably merits its own discussion). Another difficult topic -- although a slightly more advanced one -- is pointers. (I'm thinking particularly of programming in C.) With this question I'm wondering if part of the difficulty is the syntactic sugar in C that allows the following to be equivalent:
// declare array of 5 ints on the stack
int num[5];

// use array notation to change first element
num[0] = 42;

// use pointer arithmetic to change first element
*(num + 0) = 42;

With array notation, we are explicit with 0-indexing, but the logic of it isn't apparent. Yet, with pointer arithmetic, it's more clear (I think...) why we use 0: the pointer stores the base address, so dereferencing the pointer brings us to that address which is where the array logically begins.
Comfort with this leads to the topic of memory management on the heap with something like this:
// declare array of 5 ints on the heap
int *num = malloc(sizeof(int) * 5);

// use pointer arithmetic to change first element
*num = 42;

I am toying with expanding my introduction on arrays next year to include this particular use of pointers. I recognize that it would involve taking roughly a single lesson on arrays and expanding to something closer to a week-long series to tie all of these ideas together.
However, is it worth putting aside the syntactic sugar in order to understand more accurately the indexing of arrays? On the other hand, does the introduction of pointers and memory complicate the process so much so that confusion about arrays will increase rather than decrease? (I'm thinking this is a "lesson idea feedback" discussion.)

**Tags:** lesson-ideas, arrays, c, syntax, abstraction

> **Comments:**
> **username_4**: Hard to remember back this far, but the malloc example is useful even if you skip over the work underneath. It exposes the machinery inside the black box just enough.  
> **username_5**: Is this an AP CS class, or something where you have more free reign in the curriculum?  And what is the general language of the course?  
> **username_0**: Yes, AP CS Principles, more specifically CS50 AP. The curriculum includes pointers in an optional unit, but my gut says to include it regardless. We spend about a week in Scratch for general programming concepts and then focus on C for the rest of the semester before also going over basic Python the second semester.  
> **username_6**: Note: `sizeof(myarray)` gives the size of your array, (if I remember correctly) in bytes. Where as `sizeof(mypointer)` gives the size of a pointer (4 or 8, depending or architecture). Also arrays can-not be passed to another routine, only a pointer is passed.  
> **username_2**: I agree with @username_9 that 0-based arrays are a little strange but pointers are much much more difficult. Better to not confuse things by combining the two until both concepts are consolidated in students' minds.  
> **username_3**: https://www.quora.com/Why-do-array-indexes-start-with-0-zero-in-many-programming-languages describes multiple reasons for 0 indexing, including last_index - first_index should be length_of_array as well as your pointer argument.  
> **username_1**: I know a handful of seasoned C programmers, who seeing `*(pointer + integer) = z` would instantly charge at you with any sharp and heavy object they can find. It is widely believed that doing arithmetic on pointers and integers is one of the worst intentional features of C. This was a motivation for creation of a lot of other languages, who'd proudly declare that, unlike in C, this kind of pointer arithmetic is prohibited.  

---

## 7 answers

### Answer by username_9 on 2017-05-27. Score: 11

You overestimate the complexity of 0-based indexing a lot. [There is nothing complex in 0-based indexing](//cseducators.stackexchange.com/a/231/216).

On the other side, the topic of the pointers is relatively complex. I don't think it has any sense to introduce pointers earlier, than at the time when a pupil would be ready to fully feel their usefulness and use them in practice. Especially in languages like C, where the syntax of pointers is quite weird (I mean: it was a quite illogical decision for language creators to use the same syntax for arrays and pointers; as they actually have almost nothing in common: an array is usually a large-sized object containing one or more items of a specific type, a pointer is a tiny-sized object that doesn't contain even a single item, it contains only the address; pointers to items and *pointers to arrays* should have some convergence, but pointers to items and *arrays* — no more than, for example, a pointer to the item of a specified type and *a structure whose first member is of specified type*).

> **Comments:**
> **username_0**: I didn't refer to it as complex, just challenging. I don't think it is a difficult idea. Based on my experience with students in the classroom, the adjustment to starting at 0 "feels" different and odd at first. I'm just seeking ways of making it feel more intuitive by grounding it in real-life examples, hence the motivation for the other thread.  
> **username_10**: Pointers are (unfortunately for beginners) a must-have in early stage of C teaching, as you certainly want the students to use a procedural approach for programming (decomposition of actions as small functions, thus transmitting parameters by copy and by reference).  
> **username_9**: @MichelBillaud, yes, I consider it a big downside of C. I personally started from Pascal and therefore, when being beginner, I had by-ref-parameters without pointers. Maybe it's better to start learning C without by-ref parameters (i.e. pass in by copy, pass out through result or through a member of result structure) in the beginning?  
> **username_10**: @username_9 Maybe it's better to learn the basics of programming with a more civilized language, and keep C for occasions where you really need low level stuff for efficiency (which drastically excludes transmitting copies of things when not necessary). C as a first language defeats its own purpose.  

---

### Answer by username_11 on 2017-05-27. Score: 10

This is a *great* explanation of why 0-indexing exists. As someone who barely knows what a pointer is, your explanation made perfect sense. If you wanted to dumb it down a little you could phrase it as:

> When you create an array, the variable you assign that array to is actually a pointer to the first element. Lets create an array `num`. When you want to modify the array, to get a pointer to the first element you want to add 0 to `num`, because `num` points to the first element. For the second element, you add 1 to `num` because `num` is a pointer to the first element and the second is one after the first. Then for the third element, you add 2 to `num, and so on, so that the first is adding 0, the second is adding 1, and the third is adding 2.

A useful resource is [this website](https://web.archive.org/web/20171112035729/https://www.cs.umd.edu/class/sum2003/cmsc311/Notes/BitOp/pointer.html) which explains how `num[i]` is syntactic sugar for pointer arithmetic (`*(num+i)`).

I think that this discussion will increase clarity and be very useful because it makes sense as a logical way to implement arrays and revels a cool thing about the language. I'm not sure that you have to talk about memory, but talking about pointers is certainly worthwhile for this example.

> **Comments:**
> **username_0**: Thanks for sharing that link. I'll use to supplement this lesson should I likely go this direction next year.  
> **username_11**: @username_0 Glad I could help. Because this is about AP CS Principles, I guess I should add that this is from the perspective of someone who is taking the class next year.  

---

### Answer by username_3 on 2017-07-03. Score: 6

**Draw ongoing attention to the potentially confusing point by banning cardinal descriptions of an element's position.**

Avoid referring to the "first element" or "second element" and talk only about "element at index 0" or "at index 1." Insist that your students speak only of indices and not of position in a sequence. If you ever use cardinal numbers in human language, you might get it right ("the second element is the element at index 1") but beginners will stumble, as you point out. If you correct with a smile when a student speaks to refer to an element with cardinal numbers, the class will join you in "catching" cardinal language. While there's nothing wrong with cardinal language, a playful "ban" gives students the opportunity to think through the point of confusion every time someone speaks about an index.

Your question as to "does teaching pointer arithmetic reduce student mistakes related to 0-indexing" is an empirical question. I don't know, but I'm suggesting another treatment, the playful ban. My evidence is mere anecdotal experience that this works in my classroom with my teaching style. There does not exist, to my knowledge, any report in the CS ed literature comparing students in a class that "prohibits" cardinal description by friendly censors vs. a class that does no such thing. As CS educators, we have a long way to go before we can boast of a compendium of empirically derived pedagogical content knowledge. Physics has the tome I envy: a 4-pound 11-pt-font book summarizing peer-reviewed measurement of effects of classroom nuances like this. Please, CS ed, produce something akin to [*Teaching Introductory Physics*](http://rads.stackoverflow.com/amzn/click/0471137073). Guzdial's [*Learner-centered Design of Computing Education*](http://rads.stackoverflow.com/amzn/click/1627053514) is a wonderful book, but we have a long way to go to match the physics education community's understanding of their craft.

> **Comments:**
> **username_3**: @nocomprende then four-th and fourth would refer to a[4] and a[3]. Ditto for 6, 7, 8, ...  
> **username_5**: @BennettBrown My [most recent question](https://cseducators.stackexchange.com/questions/3152/books-about-pedagogical-research-within-our-field) might interest you.  (And I'd be highly interested in your response)  

---

### Answer by username_6 on 2017-05-28. Score: 4

I am not advocating teaching pointers to explain 0-indexing (see mine and other's answers on your other question for how to do that). However, if we have good reason to teach pointers, here is a tip that helped me when I was learning. I have also shared these ideas with other pupils, and they started to make progress.
I find code involving pointers confusing: is it a pointer, or is it the real thing. To help me with this I adopted a little bit of Hungarian notation (I don't generality advocate Hungarian notation in strongly typed languages, but for pointers, it is a great help.
Prerequisite
It is important to ensure that all variables and routines have good names:

Routines that do something (change something), should not return a value and should have a verb name (or verb phrase). (one style would allow returning of status, this is needed in non-object-oriented programming.)

Booleans should be adjectives (start with is, has was (no future tense).

Variables and routines returning a non-boolean value, should be a noun (or noun phrase).


The notation
Append a _pt to the end of the name of all pointers.
Explanation
int numberOfCats     /*  numberOfCats is an integer*/
int *numberOfDogs_pt /* *numberOfDogs_pt is an integer*/


numberOfCats  /*a real integer*/
&numberOfCats /*a pointer to an integer*/

*numberOfDogs_pt /*a real integer, like what was declared*/
numberOfDogs_pt  /*a pointer, as in its name*/

If you see a *???_pt then you can cancel out the * and the _pt, it is in this context, not a pointer, but I can drop the * to make it a pointer. Where a variable does not have a _pt, there is no * to drop, however, I can add a &. & works as the opposite of a *.
*&numberOfCats is same as numberOfCats

Hope this is useful.


---

### Answer by username_12 on 2018-05-29. Score: 3

Let me suggest, pretty strongly, that you may be mixing up too many ideas in too short space for novices to grasp in one go. Spread it out. There is no real reason to introduce arrays along with pointers, nor to give a complex reason for zero indexing at the start. In C, you don't want to avoid it altogether, of course, but you don't dump the whole load at once.
Step one
I'd suggest that you first present arrays in a simple way, using all of the available sweeteners that there is (syntactic sugar). Something like this tutorial is pretty clear. It enables the use of arrays for nearly all purposes.
You can describe an array as a "contiguously stored block of values of the same type." One easy way to talk about zero indexing in this context is to think of the index as the distance from the start. If you aren't asked about what distance means at the start you can just ignore it, but if asked, you can talk, briefly, about each type has a "size" and the distance is measured in units of this size. Thus the "first" element is at distance 0, so has index 0.
Step two
Once arrays are solidly integrated into the students' thinking process you can introduce pointers in general, but not yet connected to arrays. Again, the Tutorials Point introduction is pretty much at the level that is needed.
But you have introduced two concepts and the pedagogy was to keep them separate initially so that each can be learned on its own merits. Now you can merge the two ideas and will then deepen the understanding of both.
Step three
This third tutorial explains it quite well. Note that since you used the "distance" metaphor for indexing initially it all comes together. In an array of doubles,
double balance[5] = {1000.0, 2.0, 3.4, 17.0, 50.0};

the measurement is the size of a double. the compiler knows this so that in:
*(balance + 2) : 3.400000
adding 2 is sufficient since the compiler knows the measurement scale from the declaration. So the 2 means 2 units where a unit is sizeof double.
Summary
The key idea here is to teach the three topics separately in a way that enables use but also avoids requiring too many more-or-less independent ideas to be needed in any one discussion. In the third part (pointer to an array) you remind them of what they already know and show them an alternate way to think about things that can reinforce what they know (contiguous block of values of the same type + distance) and make it actually computational.
You can emphasize that both the "contiguous" part and the "same type" part are essential in this computation. This gives you a hook to discuss variations, say linked-list vs arrays or homogeneous vs heterogeneous structures.


---

### Answer by username_7 on 2021-05-30. Score: 1

In C, when you declare an array of type int like so
int n = 500;
int *a = malloc(n*sizeof(int));

the name a stores the heap memory address of a chunk of memory. When you use the sqaure-bracket operator as in a[k], you "go" to address a.   Baked into the pointer data type is knowledge of the size of the type you have in your array; hence a[k] means that after you go to a, you move over k integer spaces.  Note that the compiler generates the same code for a[k] and *(a + k).
A similar thing occurs if you allocate this memory on the stack.
Other languages have inherited this convention from C. One example that does not is R; it uses 1-based indexing. This is the explanation I give to my students, and they find it very reasonable.

> **Comments:**
> **username_7**: Also note: the array's name is const; you cannot increment it.  

---

### Answer by username_8 on 2021-03-29. Score: 0

This was too long for a comment (Please view it as such)

1. **Way-of-teaching-reference**: I can recommend the way Jerry Cain (Stanford University) introduced the concepts in C in CS107 (Programming Paradigms) (available on iTunes-U).
2. **Problem mixing**: I think you're mixing two problems:

   * (a) C syntax is difficult
   * (b) pointer introduction  
       
     So `does the introduction of pointers and memory complicate the process so much so that confusion about arrays will increase rather than decrease?` -> I wouldn't say so. I would rather say "introducing them in C might be counterproductive".   
       
     Remember, that your `pointing finger` is also a pointer: It can point at a bridge without being the bridge. If it's in your pocket it points at nothing. Your finger can also point at a glass of water. If you close your eyes, you will not recognize, if someone takes away the glass. So assuming your finger always points at the glass can be "dangerous". Someone might exchange it for spinach soup.
3. **Nothing new**: Pointers and arrays are a very common concept in the real world. I see many educators overcomplicating explanations. Here's a guy explaining pointers by paper in drawers: (Japanese audio) <https://www.youtube.com/watch?v=qhquKBfPyDs>

   * Every drawer has a paper saying "chocolate" (like the type in programming), where to find the next hint (pointer), and the information on how many hints are there to come (like the `*` in C).
   * He looks at all hints and finally finds the chocolate.


---

