macOS C Programming Variable Scope and Pointers

[cybrscot]

It'll hit you hard in the next chapter of both books when they introduce arrays after pointers. It seems like King already gave you arrays, but will come back to it now that you have pointers. Learn C on the Mac will introduce malloc and free in the chapter after that. King will wait until Chapter 17 to introduce malloc.

Patience. You're not done with either book, they have to introduce a concept before they show you how to put it together with something else to build something larger.

B

I actually haven't gotten that far in Kings book yet, I switched over to C on the Mac to see things from another perspective. C on a Mac is much less detailed and moves along much more quickly, so while I was trying to understand pointers, I figured I'd jump out of place in Kings book to see what he had to say and get some more details. I'm glad I did because I learned that pointers can be declared and initialized, and need to be of a type, just like other variables. C on a Mac didn't go into that detail yet. But that's easy stuff to learn so they should've IMHO.

 

[notjustjay]

There are lots of uses for pointers. One is dynamic memory allocation.

Suppose you have a program that asks the user to type in a large number of values. You could do this:

int valueArray[100];

And your program will allow up to 100 values to be input.

But what happens if there could be thousands of entries? Maybe you really have no idea how many entries the user wants to enter.

You could do this:

int valueArray[10000];

or maybe even

int valueArray[1000000];

And that would maybe prepare you for a worst-case scenario.

But what happens if your user actually only had 3 things to input? Here you've created an array of a million elements and you really only needed 3. That's an awful waste of memory that is set up at compile-time, and carted around for the entire time your program runs, even if it is never used. And your program might not even run on some computers with less RAM.

Or what happens if a million entries actually isn't enough? Maybe the user had two million entries? Now you have to rewrite your program to support more.

Ideally your program could ask the user first, "how many items are there?" and then create an array big enough to store exactly that many items. Or an even better trick would be to automatically keep making it bigger as more and more entries are being input. Turns out, it can, by dynamically allocating chunks of memory and then deleting them when it's done using them. And when you create a new block of memory, you access it with... a pointer.

That's a simple example using simple integer variables. It might not make a lot of sense ("why would I want to do this?") but consider real-world applications like word processors and databases. A word processor has no idea if you're going to write a quick two-paragraph note or a thousand-page novel. It has to dynamically allocate more memory the more you type. A database might be loading in a small file with 3 entries, or a very large file with millions. It has to dynamically allocate more memory for the larger file.

This will also start to make a lot more sense once you get into structs, and how they can link to each other. Then you get to the really fun stuff like linked lists and trees!

(There's also the matter of "where" the memory is coming from, e.g. stack versus heap allocation, but you'll get to that later too...)

 

[Sydde]

Perhaps the most important use of pointers is to pass a parameter of indefinite size. This is very important because computers handle data that changes in size, otherwise they would not be good for much.

The best example would be a string. If your function does something with a string, typically it will not be written for a string of a specific length. Hence, it will receive a pointer to the string of characters that it will parse or modify or handle in some other way. Because of the way programs work, trying to pass an actual string of indefinite length as a function parameter is possible be very impractical.

When you get to Objective-C, where objects communicate with other objects of possibly unknown type, pointers become the obvious thing to pass.

 

[balamw]

I actually haven't gotten that far in Kings book yet, I switched over to C on the Mac to see things from another perspective. C on a Mac is much less detailed and moves along much more quickly, so while I was trying to understand pointers, I figured I'd jump out of place in Kings book to see what he had to say and get some more details. I'm glad I did because I learned that pointers can be declared and initialized, and need to be of a type, just like other variables. C on a Mac didn't go into that detail yet. But that's easy stuff to learn so they should've IMHO.

Generally this is a good approach, though I would suggest that you finish Learn C on the Mac, or at least get to Chapter 9 before you dismiss the way the author is introducing things. It looks like much of what we are saying is coming shortly. A lot of complexity is in the next two chapters with complex and dynamic data structures.

After Chapter 9 Learn C on the Mac switches over to dealing with files and "Advanced Topics" which should be separable from the main text.

B

 

[firewood]

Your problem might be in trying to learn a programing language before even learning what a computer is or how a computer works.

Try a kids picture book with a title such as "How Computers Work", or some such. Read it before trying to learn how to program. Maybe there's a good web site on the topic.

Then you will know why everything has an address and why an address is obviously needed.

Your beginning programming book is severely broken if it doesn't tell you this stuff or at least recommend it for reading or as pre-requisite knowledge.

 

[balamw]

Then you will know why everything has an address and why an address is obviously needed.

I think that's a bit over the top. It certainly is possible to program without any knowledge of pointers or addresses. Many of us did just fine in BASIC without ever using a pointer directly. Sure you got PEEK and POKE, but those were usually used to interface with the hardware and not variables.

B

 

[Sydde]

I think that's a bit over the top. It certainly is possible to program without any knowledge of pointers or addresses. Many of us did just fine in BASIC without ever using a pointer directly. Sure you got PEEK and POKE, but those were usually used to interface with the hardware and not variables.

B

C is pretty darn close to the hardware for a high level language, it can allow for some pretty stunning mistakes. I think it would at least be a good idea for a book that teaches C to touch upon the critical areas pertaining to "automatic" variables and the stack as well as managing regions of memory so that block overflows fail to happen. Really, I think some very simple vanilla machine language understanding should be required for any serious programmer.

 

[firewood]

Many of us did just fine in BASIC without ever using a pointer directly. Sure you got PEEK and POKE, but those were usually used to interface with the hardware and not variables.

With only 64kB of memory or sometimes much less, kids pretty much learned that everything had to fit somewhere in a limited linear range, even if they never actually peeked or poked into that linear range.

 

[balamw]

C is pretty darn close to the hardware for a high level language, it can allow for some pretty stunning mistakes. I think it would at least be a good idea for a book that teaches C to touch upon the critical areas pertaining to "automatic" variables and the stack as well as managing regions of memory so that block overflows fail to happen. Really, I think some very simple vanilla machine language understanding should be required for any serious programmer.

With only 64kB of memory or sometimes much less, kids pretty much learned that everything had to fit somewhere in a limited linear range, even if they never actually peeked or poked into that linear range.

I don't disagree with either of these statements or the sentiments behind them, however I do think you can learn to write very useful code in many environments that don't require intimate knowledge of pointers. I agree that C isn't one of them if you want to take it seriously.

I haven't read either of the books that cybrscot is using thoroughly, though I have peeked at bits of them in order to decipher some of his threads. In some cases the information is there it's just not immediately visible if you don't already know what you are looking for.

In this case neither book has even introduced malloc yet, and they will. I presume when they get to that they will talk about the heap and the stack and all the wonderful complexity that is entailed with managing memory, and at that point pointers will become a lot clearer.

B

 

[dmi]

Can you think of a program you could write that uses arrays or strings?
In C, both of them take advantage of pointers.

 

[balamw]

Can you think of a program you could write that uses arrays or strings?
In C, both of them take advantage of pointers.

Arrays don't have to use pointers explicitly. For example http://knking.com/books/c2/programs/reverse.c from one of the books that cybrscot is using:

/*********************************************************
 * From C PROGRAMMING: A MODERN APPROACH, Second Edition *
 * By K. N. King                                         *
 * Copyright (c) 2008, 1996 W. W. Norton & Company, Inc. *
 * All rights reserved.                                  *
 * This program may be freely distributed for class use, *
 * provided that this copyright notice is retained.      *
 *********************************************************/

/* reverse.c (Chapter 8, page 164) */
/* Reverses a series of numbers */

#include <stdio.h>

#define N 10

int main(void)
{
  int a[N], i;

  printf("Enter %d numbers: ", N);
  for (i = 0; i < N; i++)
    scanf("%d", &a[i]);

  printf("In reverse order:");
  for (i = N - 1; i >= 0; i--)
    printf(" %d", a[i]);
  printf("\n");

  return 0;
}

The book introduces arrays twice, once before pointers then once after.

You can also do a lot with only literal strings which again don't need explicit pointers.

B

 

[firewood]

I think that's a bit over the top. It certainly is possible to program without any knowledge of pointers or addresses.

Lots of things are possible. It might be possible to write a complete large original Objective C program with zero bugs during the entire development process. The actual probability of that is pretty close to zero.

Once someone has to debug a gnarly problem with a Mac or iPhone app, not knowing about memory addresses is a near fatal handicap. Thus, if someone can't answer a pointer question during the technical portion of a job interview, that's a near automatic disqualification from the point of view many OSX/iOS hiring managers.

 

[lee1210]

Lots of things are possible. It might be possible to write a complete large original Objective C program with zero bugs during the entire development process. The actual probability of that is pretty close to zero.

Once someone has to debug a gnarly problem with a Mac or iPhone app, not knowing about memory addresses is a near fatal handicap. Thus, if someone can't answer a pointer question during the technical portion of a job interview, that's a near automatic disqualification from the point of view many OSX/iOS hiring managers.

If someone has never used %p they've either never dealt with a serious memory problem, or they've always been able to readily reproduce issues like this (so they can get at it with a debugger). They would have to be really lucky in that case.

-Lee