[mascara-docs.git] / lang / C / the.ansi.c.programming.language / notes.accompany.ansi.c / sx8c.html
| blob | 9f971758fee7ff32fa6c8ae4372267eba116a1fc |
2 <!-- This collection of hypertext pages is Copyright 1995, 1996 by Steve Summit. -->
3 <!-- This material may be freely redistributed and used -->
4 <!-- but may not be republished or sold without permission. -->
5 <html>
6 <head>
13 </head>
14 <body>
17 page 97
18 <p>For some people,
19 section 5.3 is evidently the hardest section in this book,
20 or even if they haven't read this book,
21 the most confusing aspect of the language.
22 C introduces a novel and,
23 it can be said,
24 elegant integration of pointers and arrays,
25 but there are a distressing number of ways of misunderstanding arrays,
26 or pointers, or both.
27 Take this section very slowly,
28 learn the things it does say,
30 (i.e. don't make any false assumptions).
31 </p><p>It's not necessarily true that
32 ``the pointer version will in general be faster'';
33 efficiency is
34 (or ought to be)
35 a secondary concern when considering the use of pointers.
37 </p><p>On the top half of this page,
38 we aren't seeing anything we haven't seen before.
39 We already knew
40 (or should have known)
41 that the declaration
47 </p><p>What's new on this page are first the nice pictures
49 I think they're the right way of thinking about arrays and pointers in C)
50 and the definition of pointer arithmetic.
51 If the phrase
53 alarms you;
55 don't worry.
56 You hadn't
57 known this,
58 and you aren't expected even to have suspected it:
60 is simply that it's defined that way,
61 as the sentence says.
62 Furthermore,
63 subtraction works in an exactly analogous way:
64 If we were to say
71 about the size of the objects pointed to.
72 Adding 1 to a pointer
73 (or subtracting 1)
74 always means to move over one object of the type pointed to,
75 to get to the next element.
76 (If you're too worried about machine addresses,
77 or the actual address values stored in pointers,
78 or the actual sizes of things,
79 it's easy to mistakenly assume that adding or subtracting 1
80 adds or subtracts 1 from the machine address,
81 but as we mentioned,
82 you don't have to think at this low level.
83 We'll see in section 5.4 how pointer arithmetic is actually
84 scaled,
85 automatically,
86 by the size of the object pointed to,
87 but we don't have to worry about it if we don't want to.)
88 </p><p>Deep sentence:
90 and by extension,
91 all pointer arithmetic,
94 </blockquote></p><p>This aspect of pointers--that arithmetic works on them,
95 and in this way--is one of
96 several vital facts about pointers in C.
97 On the next page, we'll see the others.
99 </p><p>Deep sentences:
100 <blockquote>The correspondence between indexing and pointer arithmetic is very close.
101 By definition,
102 the value of a variable or expression of type array
103 is the address of element zero of the array.
104 </blockquote>This is a fundamental definition,
105 which we'll now spend several pages discussing.
106 </p><p>Don't worry too much yet about the assertion that
110 we've been taking the address of array elements for several pages now.
111 What we don't
112 know--we're
113 not yet in a position to be surprised about it or
114 not--is
117 </p><p>In some languages,
118 the value of an array is the entire array.
119 If an array appears on the right-hand sign of an assignment,
120 the entire array is assigned,
121 and the left-hand side had better be an array, too.
122 C does not work this way;
123 C never lets you manipulate entire arrays.
124 </p><p>In C,
125 by definition,
126 the value of an array,
127 when it appears in an expression,
128 is a pointer to its first element.
129 In other words,
131 If this statement makes any kind of intuitive sense to you at
132 this point,
133 that's great,
134 but if it doesn't,
135 please just take it on faith for a while.
136 This statement is a fundamental
138 definition about arrays and pointers in C,
139 and if you don't remember it,
140 or don't believe it,
141 then
142 pointers and arrays will never make proper sense.
143 (You will also need to know another bit of jargon:
144 we often say that,
145 when
146 an array appears
147 in an expression,
149 </p><p>Given the above definition,
150 let's explore some of the consequences.
151 First of all,
152 though we've been saying
154 </pre>we could also say
155 <pre> pa = a;
157 (i.e. as it sits there all alone on the right-hand side)
159 Secondly,
162 That is, instead of writing
164 </pre>we could,
165 if we wanted to,
166 instead write
168 </pre>Why would this possibly work?
169 How could this possibly work?
172 which is by definition a pointer to its first element.
174 To make things clear,
175 let's pretend that we'd assigned the pointer to the first element
176 to an actual pointer variable:
178 </pre>Now
179 we have
186 Thus,
187 for whatever it's worth,
190 </p><p>The idea of the previous paragraph isn't worth much,
194 The significant fact is that this little correspondence between
196 holds for more than just arrays.
199 as we learned on page 98,
201 This time, using the ``other'' notation
202 (array instead of pointer,
203 when we thought we had a pointer)
204 can be more convenient.
205 </p><p>At this point,
208 You may be wondering how you're going to remember that you can do this,
209 or remember what it means if you see it in someone else's code,
210 when it's such a surprising fact in the first place.
211 There are several ways to remember it;
212 pick whichever one suits you:
213 <OL><li>It's an arbitrary fact,
214 true by definition;
215 just memorize it.
216 <li>If,
220 (as we proved a few paragraphs back);
224 <li>Deep sentence:
227 the two forms are equivalent.''
228 <li>An array is
229 a contiguous block of elements of a particular type.
230 A pointer often points to
231 a contiguous block of elements of a particular type.
232 Therefore, it's very handy to treat
233 a pointer to a contiguous block of elements
235 it were an array,
237 <li>
238 [This is the most radical explanation,
239 though it's also the most true;
240 but if it offends your sensibilities
241 or only seems to make things more confusing,
242 please ignore it.]
244 you weren't really subscripting an array at all,
246 into a pointer to its first element.
248 finds itself working on pointers,
249 and it's a simple identity
250 (another definition)
252 </OL>(But do pick at least one reason to remember this fact,
253 as it's a fact you'll need to remember;
255 </p><p>The authors point out that
256 ``There is one difference between an array name and a pointer
257 that must be kept in mind,''
258 and this is quite true,
259 but note very carefully that there is
260 in fact
262 between an array and a pointer.
263 When an array name appears in most expressions,
264 it turns into a pointer
265 (to the array's first element),
267 You may hear it stated that ``an array is just a constant pointer,''
268 and this is a convenient explanation,
269 but it is a simplified and potentially misleading explanation.
270 </p><p>With that said,
273 cannot mean anything.
274 </p><p>Deep sentence:
275 <blockquote>When an array name is passed to a function,
276 what is passed is the location of the initial element.
277 </blockquote>Though perhaps surprising,
278 this sentence doesn't say anything new.
279 A function call,
280 and more importantly,
281 each of its arguments,
282 is an expression,
283 and in an expression,
284 a reference to an array is always replaced by a pointer to its first element.
285 So given
287 f(a);
289 but rather just a pointer to its first element.
290 For an example closer to the text on page 99,
291 given
293 int len = strlen(string);
295 (recall that C never lets you do anything with
296 a string or
297 an array all at once),
298 but rather just a pointer to its first element.
299 </p><p>We now realize that we've been operating under a gentle fiction
300 during the first four chapters of the book.
302 which seemed to accept an array of characters,
303 and whenever we thought we were passing arrays of characters to these routines,
304 we were actually passing pointers.
305 This explains,
306 among other things,
308 the arrays in the caller,
309 even though we said that call-by-value meant that functions
310 can't modify variables in their callers since they receive
311 copies of the parameters.
312 When a function receives a pointer,
313 it cannot modify the original pointer in the caller,
316 </p><p>If that doesn't make sense,
317 make sure you appreciate the full difference
318 between a pointer and what it points to!
319 It is intirely possible to modify one without modifying the other.
320 Let's illustrate this with an example.
321 If we say
323 char b[] = "world";
324 </pre>we've declared two character arrays,
326 each containing a string.
327 If we say
328 <pre> char *p = a;
331 If we then say
332 <pre> *p = 'H';
338 </p><p>If we say
339 <pre> p = b;
340 </pre>on the other hand,
343 In a sense,
345 has changed--it
350 </p><p>Since,
351 as we've just seen,
352 functions never receive arrays as parameters,
353 but instead always receive pointers,
354 how have we been able to get away with defining functions
356 which seemed to accept arrays?
357 The answer is that whenever you declare an array parameter to a function,
358 the compiler pretends that you actually declared a pointer.
359 (It does this mostly so that
360 we can get away with the ``gentle fiction''
361 of pretending that we can pass arrays to functions.)
362 </p><p>When you see a statement like
364 (as in fact you see at the top of page 100),
365 you can be sure that
366 (and you must remember that)
368 talked about.
369 Anywhere else,
370 arrays and pointers are quite different,
371 as we've discussed.
373 (at the end of section 5.3)
374 may be easier to understand
377 which,
378 as we've seen,
380 </p><p>With the examples in this section,
381 we begin to see how pointer manipulations can go awry.
383 most of our pointers were to simple variables.
384 When we use pointers into arrays,
385 and when we begin using pointer arithmetic
386 to access nearby cells of the array,
387 we must be careful never to go off the end of the array,
388 in either direction.
389 A pointer is only valid if it points to one of the allocated
390 cells of an array.
391 (There is also an exception for a pointer just past the end of an array,
392 which we'll talk about later.)
393 Given the declarations
395 int *pa;
396 </pre>the statements
397 <pre> pa = a;
398 *pa = 0;
402 *pa = 5;
406 *pa = 9;
408 </pre>are all valid.
411 and modify some of those cells
413 (As an exercise,
415 receives the value of its own index.
417 </p><p>However,
418 the statements
419 <pre> pa = a;
425 *pa = 0; /* WRONG */
426 </pre>and
427 <pre> int *pa2;
429 pa2 = pa + 10; /* WRONG */
430 pa2 = pa - 10; /* WRONG */
431 </pre>are all invalid.
433 but then use overly-large offsets
436 The statements in the last set of examples
438 Even though no attempt is made to access the nonexistent cells,
439 these statements are illegal, too.
440 Finally,
441 the code
443 int *pa, *pa2;
445 pa2 = pa + 10; /* WRONG */
446 *pa2 = 0; /* WRONG */
447 </pre>would be very wrong,
448 because it not only computes a pointer to the nonexistent
450 but it also tries to store something there.
451 </p><hr>
452 <p>
453 Read sequentially:
458 </p>
459 <p>
463 </p>
464 </body>
465 </html>