RSS

Monthly Archives: December 2011

Pointers: A Five Minute Primer

Whenever anyone thinks about C, the first thing that comes to mind is pointers. In order to harness the full capabilities of what is a syntactically minimal programming language, you have to understand how C handles memory management, and how you can actually manipulate computer memory using C constructs. Here are the essentials:

What is a pointer?

The most basic way to deal with data in a function is to declare a variable and then initialize it with a value. For example, in the following case:

int x = 5;

We can think of the data value 5 being stored directly in a slot in memory named “x.” In the case of a pointer, however, the memory slot does not directly store the data. Instead it stores a memory address at which we can find the data. So if we look in slot “x”, we will find something to the effect of 0x714ae023, a memory address (in hexadecimal).

How to declare a pointer

Building on our previous example, let’s say you want a pointer to an integer (pointer-to-int). You would declare it as follows:

int* myIntPointer;

Thus the variable x is not of type int, but of type int*, a pointer-to-int (note you can also write int *x, but the former is better practice because it is less confusing; more on that in a second).

Pointer dereferencing

After you have declared a pointer variable, you might be tempted to say something like this:

myIntPointer = 5;

While the above is valid C code and will compile, it does not have the desired effect. What you have to remember is that myIntPointer stores a memory address. So rather than storing the data value 5, the computer (and your program) will think you are storing the memory address 5, and will look at that address for the data value.

So what do you do instead? In order to access and set the data stored at the memory address pointed to by your pointer, you use *, the pointer dereference operator. So in order to store the data value 5 at the address pointed to by your pointer, you would do this:

*myIntPointer = 5;

But wait, that’s still not correct…yet. Although you have declared the pointer variable (and thus the memory in which to store the address itself), you have not yet allocated memory in which to store the data value. When you first initialize. You need to use malloc, which is the C function that allocates a chunk of memory of the desired size and returns the address of that memory. It looks like this:

int* myIntPointer;
myIntPointer = malloc(sizeof(int));
*myIntPointer = 5;

One more thing to know. Any memory you have malloc-ed will not be reuseable by your program unless you explicitly tell your program to get rid of the data (see the discussion of stack vs. heap memory). So once you are done using a pointer and the relevant memory, you need to call free:

//code that uses myIntPointer

free(myIntPointer);

And that’s it! Then your program will be able to utilize the memory for another purpose, perhaps when you malloc memory for other data.

Aside: Pointers and structs

Let’s say you have the following struct declaration and intializations:

struct widget
{
    char name[20];
    double price;
};

int main()
{
    //random source code

    struct widget baseball = {"baseball", 9.99};
    struct widget* football = {"football", 19.90};
    ...
}

Normally, if you have a struct variable, as in the case of the ‘baseball,’ you use the dot (.) operator to access/change the name and price properties of the widget as follows:

{
    ...
    printf("%s", baseball.name);
    baseball.price = 5.00;
    ...
}

However, when you have a pointer-to-struct, you use the pointer dereference operator (->), as follows:

{
    ...
    printf("%s", football->name);
    football->price = 10.00;
}

How does C manage memory, and where do pointers fit in?

In C, there are two types of memory, local (or stack) memory and heap memory. Whenever a function is first called, allocates memory for all its variables in an area of memory called the stack. It is called the stack because every time a new function is called, your program allocates memory “on top” of the previous memory, and reads from that memory until the called function terminates. At that point, the program, having maintained a pointer to the calling function, will “pop” the memory for the called function off the top of the stack (i.e. deallocate it) and return to the previous function. That’s why if you declare a variable and store data to it within a function, the data is inaccessible to other functions once that function has terminated.

So how do we avoid this constraint? This is where heap memory comes in. Heap memory is a separate block of memory accessible to your program, but it is only used when you as a programmer explicitly decide to use it. In C, this would take the form of a malloc call, in C++, by use of the keyword new, and in Objective-C, with the message alloc sent to the classname. This provides you with memory that will persist beyond the lifetime of the function in which it is allocated; memory in the heap is not subject to the same lifetime constraints of stack memory. Thus, by maintaining a pointer to the malloc-ed memory, you can access and manipulate the stored data across multiple functions.

Think you understand pointers? Then here’s your first quiz: Knowing what you now know about memory management in C, what is the conceptual difference between:

struct widget myWidget;
myWidget.name = "baseball";
myWidget.price = 10.0;

and:

struct widget* myWidget = malloc(sizeof(struct widget));
myWidget->name = "baseball";
myWidget->price = 10.0

The answer, if you understand the stack and heap memory, is actually quite simple. The memory for the first struct is allocated upon function call from the stack, so the data persists only the length of the function. As long as the function has not finished executing (e.g. you are currently executing a called function), you can access and manipulate the data all you want. However, as soon as the function terminates, so too does the data.

The second version, in which the function maintains a pointer to the data, is different because the data is stored in memory allocated from the heap. This data will persist even after the function terminates, allowing it to be accessible (as long as you have a pointer to it) until you deallocate the memory with free.

If you’re looking for more help, check out Nick Parlante’s guide to pointers in the Stanford CS Library. And of course, if you have any questions for me, leave a comment! I’d be glad to help.

 
Leave a comment

Posted by on December 26, 2011 in General, Programming

 

Tags: , , , , , , , , ,

iPhone Programming, Part II

Alrighty, for those of you on the edge of your seats, here’s the rest of the story (see Part I here):

After doing a quick brush up on Objective-C (a la Apple Documentation, etc), the first thing I did was purchase a copy of the Big Nerd Ranch Guide to iPhone Programming.  I am a huge fan of programming books that teach by allowing you to work through a single project over multiple chapters, because they really helps to see how each of the concepts/features you learn might fit into a larger whole.  Years ago, I had purchased a number of books from the Head First series  (specifically, Java and HTML/CSS), and I found them to be phenomenal, particularly as someone who at the time had no prior coding experience.  Some might find the books a bit “immature,” and indeed, they are no replacement for a reference books or a more heavyweight books such as Steven Prata’s C++ Primer Plus, but for someone just starting out, they would definitely be at the top of my list.

Back to my project.  After working through the first 10 chapters or so, I switched to skimming the parts that would be relevant to my app, and skipping those that weren’t (e.g. iPhone compatibility, accelerometer, location services, etc).  Then, I hit the drawing board.  My contact at the YDN had given me a few general functional specs, but the implementation was up to me.  After drawing out a few diagrams under the Model-View-Controller paradigm, I was ready to go. Basically, I needed the following:

  • An XML parser – complements of TBXML
  • A list of articles – and new story object
  • A list of favorites – and corresponding singleton object
  • An interface

I chose to implement the XML parsing using a DOM-based parser – which, rather than notifying the program when it finds a new XML tag, creates a sort of “document map” that allows you to search for items based on various tags.  Not only does TBXML store item tags, it also saves the attributes of each xml tag — so, for example, I needed to get the link for an image, I could ask for the src attribute of the image tag.

The list of articles and favorites were pretty easy to implement.  The natural way to store all of the articles was in a dynamic array, which, in the case of Objective-C means an NSMutableArray.  In the first go around, I had them written as separate classes, because the while they are similar in concept – presenting a view based on articles, the implementations were very different.  Eventually, I decided to superclass them (I know, this is supposed to happen the other way; first make a class, then subclass it) with what amounts to an abstract base class in Java or simply a normal base class in C++/Objective-C.  Actually writing my own class structure helped me understand inheritance in a way that I had previously not.  The key lessons here are:

  1. figuring out which methods would be identical among subclasses
  2. figuring out how to write code that could be extended
  3. learning when to declare [abstract] methods – cases when I knew the subclass implementations would differ (e.g. in my case, filling the arrays with data) but wanted ensure that my subclasses would implement them.

Assembling the interface was my true introduction to iPhone programming and more importantly, open source code.  I won’t get into the nitty-gritty of UITableViewControllers and the like, but my discovery of open source code is worth mentioning.  Open source code is a phenomenal way not only to learn what good code looks like, but also to understand the role software libraries play in development.  Oh yea, and if used properly, your software can end up ten times more feature-rich.  Credits here to:

  • Enormego for PullToRefresh and Lazy Image Loading (uses a cache)
  • Tom Irving for TISwipeableTableViewCells (like the twitter app; reveals a set of buttons behind a cell)
  • Facebook for their SDK and sample implementation
  • Sharekit for showing me how to email a link and post to Facebook or Twitter from within an app

Note: These last three did not make it in version 1 of the app (currently in the store).  I’m working on an update as we speak.

After I finally assembled my code, it was off to testing.  The hardest part about testing and debugging was (unsurprisingly) memory management.  While memory leaks/errors are difficult to find in C/C++, I feel that the rules for memory management are much more straightforward.  You don’t have any of the retain/release jargon concealing the basic facts about memory management in the C family of languages — memory is either allocated in the stack or in the heap (Note iOS 5+ makes Objective-C more similar to Java in its memory management with Automatic Reference Counting, although it still retains elements of its heritage). Best resource I found for finding memory leaks and understanding how to use the Leaks tool in Instruments (part of the developer software) was from Mobile Orchard.  Also, XCode has a feature you can enable called NSZombie, which will allow you to see if you are messaging a deallocated object.  If your program is crashing with a sigabrt, I would check this out.  Regardless, my recommendation: understand memory issues before embarking on a larger-scale project.  It will save you a lot of debug time in the end.

All told, it took me about six weeks to teach myself Objective-C and make the app and get approved by Apple, which was extraordinarily gratifying, both on an intellectual and personal level.  Hopefully, it will be the first of many!

Here are some screenshots of version 1.  You can download the app here:

YDN App Screenshot

YDN App Screenshot 2

 
Leave a comment

Posted by on December 21, 2011 in Programming, Projects

 

Tags: , , , , , , , , , ,

iPhone Programming and Objective-C, Part I

So two months ago the Yale Daily News was looking for a CS major to make an iPhone app for them.  They have quite and extensive business team, with a highly visible website (100,000+ views per week!) and internet presence, so this was the logical next step.  At the time, I had never worked on a real project before (all of my programming knowledge was either self-taught or limited to a few functions/methods in one or two files), but I volunteered because I figured it would be a good opportunity to try my hands at some real coding.  A few days and a couple of meetings later, I was working on the project.  Alone.  Talk about getting thrown in the deep end and learning how to swim.

First thing to do, of course,was to teach myself Objective-C.  Having worked through Stephen Prata’s C++ Primer Plus, 5th Edition I was reasonably familiar with object-oriented concepts and general C-syntax, but boy, was I in for a surprise.  At first glance, Objective-C is hideous.  You have to put [] around every method call, and its function names (or “selectors,” as they call them), can get absurdly long (try keysSortedByValueWithOptions:usingComparator: for a short one).  However, after doing some reading, I found that it was reasonably easy to learn, and actually had a lot to like:

Highlights are as follows:

  • Apple Developer’s Library – top notch; includes sample code and extensive class references
  • sending messages to nil/NULL – really neat feature that allows your program to avoid crashing when you send a message to nil.  Prevents you from having to write extra logic to deal with nil/NULL cases.
  • dynamic (run-time) typing – you can make pointers of type “id” (Objective-C’s equivalent to Java’s “Object”) – and because each instance of an object contains a reference to its class ([self class] or equivalently, self.class), you can write a single function for any data/object type, and vary the implementation within the function itself based on the data type
  • selectors  – you always know what each parameter to a function/method represents, because the selector (i.e. function name) varies based on the required parameters.  As a result, there is no function overloading; technically, you are writing an entirely new function.
Of course, there are two sides to every coin:
  • sending messages to nil/NULL – dangerous!!! Can lead to some very undesirable functionality if you’re not careful.  The feature is good if you know what you’re doing, but it can lead to some very sloppy code.  Also, the functionality does not prevent against the more common error of messaging / dereferencing a pointer to deallocated memory, so that is something to watch out for.  Good practice would be to set a pointer to nil as soon as its pointee has been deallocated.  That way, you can avoid crashes.
  • dynamic typing – code might compile but crash at run time.  Java, on the other hand, is strongly typed, so this kind of problem is less frequent.  However, in Objective-C, you can type your variables (usually pointers) if you want.
  • retain/release and memory management – it’s a pain to understand exactly how retaining works, and whose responsibility it is to release an object.  (NOTE: iOS SDK 5.0+ uses automatic reference counting, which takes the burden of memory management off the developer.  You should still understand how it works).  Here’s a good resource for memory management in Objective-C
  • It’s incorporation of C is very awkward.  Although Objective-C is functionally a superset of C, it looks very strange when you have C code in an Objective-C class.  You have to sort of treat them as two languages when coding/debugging, which can get kind of annoying
Part II (the process of making the app) to follow.
In the mean time, here’s the book I used to help me with iOS programming.

If you’re interested, you can check out my app here (it’s free).

 
1 Comment

Posted by on December 19, 2011 in Programming, Projects

 

Tags: , , , , , , ,

Hello world!

So the default title for the first post on a WordPress blog is fittingly, “Hello world!”  Seeing as how this blog is going to center on my programming-related projects and adventures, why not start it off by looking at how this classic programming greeting varies over four languages I know (okay, my correct relationship with Java would be “familiar,” but we’re not doing anything too tough):

C:  printf(“Hello world!\n”);

// <– that means comment in these languages

// \n is the escape character for a newline

C++: cout << “Hello world!” << endl;

// cout is standard output to command line; you can use it by including the “iostream” header file

// << is normally the bitwise operator, but it is overloaded for use in the iostream family.

// The function header looks something like this:    ostream&  operator<<(char * input)

Objective-C: NSLog(“%@”, “Hello world!”);

// % indicates a format, the @ indicates a string

Java: System.out.println(“Hello world!”);

// the “ln” gives you a newline

 
Leave a comment

Posted by on December 18, 2011 in General, Programming

 

Tags: , , ,