I'm fresh out of college and have been working in C++ for some time now. I understand all the basics of C++ and use them, but I'm having a hard time grasping more advanced topics like pointers and classes. I've read some books and tutorials and I understand the examples in them, but then when I look at some advanced real life examples I cannot figure them out. This is killing me because I feel like its keeping me from bring my C++ programming to the next level. Did anybody else have this problem? If so, how did you break through it? Does anyone know of any books or tutorials that really describe pointers and class concepts well? or maybe some example code with good descriptive comments using advanced pointers and class techniques? any help would be greatly appreciated.


Pretend a pointer is an array address.

x = 500; // memory address for hello;
MEMORY[x] = "hello"; 
print  MEMORY[x];

its a graphic oversimplification, but for the most part as long as you never want to know what that number is or set it by hand you should be fine.

Back when I understood C I had a few macros I had which more or less permitted you to use pointers just like they were an array index in memory. But I've long since lost that code and long since forgotten.

I recall it started with

#define MEMORY 0; 
#define MEMORYADDRESS( a ) *a;

and that on its own is hardly useful. Hopefully somebody else can expand on that logic.

Kent Fredric
I think this is a very useful excersize. Heck in a lot of embedded systems I didn't have a pointer to things allocated for me, I had an array index :).
Doug T.
for those of you downbashing me for this post, It works. I used it, I helped others with it. The fact the OS abstracts it all out for you is unimportant to the exercise.
Kent Fredric
Yeah I don't understand it, I think this is a great way to understand pointers. Arrays are easier understand than pointers, IMO, so I think its a great starting point..
Doug T.
+1  A: 

For Pointers:

I found this post had very thoughtful discussion about pointers. Maybe that would help. Are you familar with refrences such as in C#? That is something that actually refers to something else? Thats probably a good start for understanding pointers.

Also, look at Kent Fredric's post below on another way to introduce yourself to pointers.

Doug T.
+4  A: 

I used to have a problem understand pointers in pascal way back :) Once i started doing assembler pointers was really the only way to access memory and it just hit me. It might sound like a far shot, but trying out assembler (which is always a good idea to try and understand what computers is really about) probably will teach you pointers. Classes - well i don't understand your problem - was your schooling pure structured programming? A class is just a logical way of looking at real life models - you're trying to solve a problem which could be summed up in a number of objects/classes.

Per Hornshøj-Schierbeck
+1  A: 

To understand pointers, I can't recommend the K&R book highly enough.


The best book I've read on these topics is Thinking in C++ by Bruce Eckel. You can download it for free here.

Ben Hoffstein
thanksthe downloaded book comes with a lot of examples
+3  A: 

Pointers and classes are completely different topics so I wouldn't really lump them in together like this. Of the two, I would say pointers are more fundamental.

A good exercise for learning about what pointers are is the following:

  1. create a linked list
  2. iterate through it from start to finish
  3. reverse it so that the head is now the back and the back is now the head

Do it all on a whiteboard first. If you can do this easily, you should have no more problems understanding what pointers are.

+7  A: 

This link has a video describing how pointers work, with claymation. Informative, and easy to digest.

This page has some good information on the basic of classes.

Anything with claymation gets a +1 in my book.
+17  A: 

Pointers and classes aren't really advanced topics in C++. They are pretty fundamental.

For me, pointers solidified when I started drawing boxes with arrows. Draw a box for an int. And int* is now a separate box with an arrow pointing to the int box.


int foo = 3;           // integer
int* bar = &foo;       // assigns the address of foo to my pointer bar

With my pointer's box (bar) I have the choice of either looking at the address inside the box. (Which is the memory address of foo). Or I can manipulate whatever I have an address to. That manipulation means I'm following that arrow to the integer (foo).

*bar = 5;  // asterix means "dereference" (follow the arrow), foo is now 5
bar = 0;   // I just changed the address that bar points to

Classes are another topic entirely. There's some books on object oriented design, but I don't know good ones for beginners of the top of my head. You might have luck with an intro Java book.

well they're advanced topics to me, haha, I understand your examples here, but then when I try to understand someone else's code I cannot figure it out... maybe I just need more experience... thanks for the reply.
I second this. For beginners, always ALWAYS translate 'pointer' to 'address' and 'dereference' to 'travel-to-the-address', just like driving a car. pointers-to-pointers become forwarding PO-boxes -- addresses that, when you go there, you find another address instead of a storage location.
It may well be that much of that code isn't too well written. I once spent a significant amount of time trying to work out how some pointer-heavy code worked. I gave up and asked a superior. He looked at it for 2 seconds and said "Huh. That's going to cause a crash. Better fix it."Experience: The ability to look at a specimen, see it do something bizarre, and think "There's something wrong with this" rather than "There's something wrong with me".

For classes:

The breakthru moment for me was when I learned about interfaces. The idea of abstracting away the details of how you wrote solved a problem, and giving just a list of methods that interact with the class was very insightful.

In fact, my professor explicitly told us that he would grade our programs by plugging our classes into his test harness. Grading would be done based on the requirements he gave to us and whether the program crashed.

Long story short, classes let you wrap up functionality and call it in a cleaner manner (most of the time, there are always exceptions)

Jason Z
what is a "test harness"?
A test harness is code that exercises another set of code. My professor basically had a main program that called functions in our class. He would run the test, mark a grade, delete your file, and insert the next students file in his solution and repeat the whole process.
Jason Z

The book that cracked pointers for me was Illustrating Ansi C by Donald Alcock. Its full of hand-drawn-style box and arrow diagrams that illustrate pointers, pointer arithmetic, arrays, string functions etc...

Obviously its a 'C' book but for core fundamentals its hard to beat

Garth Gilmour

One of the things that really helped me understand these concepts is to learn UML - the Unified Modeling Language. Seeing concepts of object-oriented design in a graphical format really helped me learn what they mean. Sometimes trying to understand these concepts purely by looking at what source code implements them can be difficult to comprehend.

Seeing object-oriented paradigms like inheritance in graphical form is a very powerful way to grasp the concept.

Martin Fowler's UML Distilled is a good, brief introduction.


From lassevek's response to a similar question on SO:

Pointers is a concept that for many can be confusing at first, in particular when it comes to copying pointer values around and still referencing the same memory block.

I've found that the best analogy is to consider the pointer as a piece of paper with a house address on it, and the memory block it references as the actual house. All sorts of operations can thus be easily explained:

  • Copy pointer value, just write the address on a new piece of paper
  • Linked lists, piece of paper at the house with the address of the next house on it
  • Freeing the memory, demolish the house and erase the address
  • Memory leak, you lose the piece of paper and cannot find the house
  • Freeing the memory but keeping a (now invalid) reference, demolish the house, erase one of the pieces of paper but have another piece of paper with the old address on it, when you go to the address, you won't find a house, but you might find something that resembles the ruins of one
  • Buffer overrun, you move more stuff into the house than you can possibly fit, spilling into the neighbours house
Kevin Pang

To better understand pointers, I think, it may be useful to look at how the assembly language works with pointers. The concept of pointers is really one of the fundamental parts of the assembly language and x86 processor instruction architecture. Maybe it'll kind of let you fell like pointers are a natural part of a program.

As to classes, aside from the OO paradigm I think it may be interesting to look at classes from a low-level binary perspective. They aren't that complex in this respect on the basic level.

You may read Inside the C++ Object Model if you want to get a better understanding of what is underneath C++ object model.

+2  A: 

Pointers already seem to be addressed (no pun intended) in other answers.

Classes are fundamental to OO. I had tremendous trouble wrenching my head into OO - like, ten years of failed attempts. The book that finally helped me was Craig Larman's "Applying UML and Patterns". I know it sounds as if it's about something different, but it really does a great job of easing you into the world of classes and objects.

+2  A: 

We were just discussing some of the aspects of C++ and OO at lunch, someone (a great engineer actually) was saying that unless you have a really strong programming background before you learn C++, it will literally ruin you.

I highly recommend learning another language first, then shifting to C++ when you need it. It's not like there is anything great about pointers, they are simply a vestigial piece left over from when it was difficult for a compiler convert operations to assembly efficiently without them.

These days if a compiler can't optimize an array operation better then you can using pointers, your compiler is broken.

Please don't get me wrong, I'm not saying C++ is horrible or anything and don't want to start an advocacy discussion, I've used it and use it occasionally now, I'm just recommending you start with something else.

It's really NOT like learning to drive a manual car then easily being able to apply that to an automatic, it's more like learning to drive on one of those huge construction cranes then assuming that will apply when you start to drive a car--then you find yourself driving your car down the middle of the street at 5mph with your emergency lights on.

[edit] reviewing that last paragraph--I think that may have been my most accurate analogy ever!

Bill K
any languages you suggest to learn first? would python be a good choice? I'm currently trying to learn php as well as c++, syntax wise they're pretty similar.
C# and Java are good because they are compile-time checked and honestly that's a really good habit to get into.If you want to just fool around, Python is good.If you are doing a web site, Ruby on Rails--period.
Bill K
Oh, and if you REALLY want to learn bleeding edge programming concepts, look at Scala. Honestly that may be the best because of all the concepts it exposes you to right off.Hascal and Lisp are also known for teaching good programing concepts.
Bill K
+1  A: 

Learn assembly language and then learn C. Then you will know what the underlying principles of machine are (and thefore pointers).

Pointers and classes are fundamental aspects of C++. If you don't understand them then it means that you don't really understand C++.

Personally I held back on C++ for several years until I felt I had a firm grasp of C and what was happening under the hood in assembly language. Although this was quite a long time ago now I think it really benefited my career to understand how the computer works at a low-level.

Learning to program can take many years, but you should stick with it because it is a very rewarding career.

Ashley Davis

Classes are relatively easy to grasp; OOP can take you many years. Personally, I didn't fully grasp true OOP until last year-ish. It is too bad that Smalltalk isn't as widespread in colleges as it should be. It really drives home the point that OOP is about objects trading messages, instead of classes being self-contained global variables with functions.

If you truly are new to classes, then the concept can take a while to grasp. When I first encountered them in 10th grade, I didn't get it until I had someone who knew what they were doing step through the code and explain what was going on. That is what I suggest you try.

+1  A: 

There's no substiture for practicing.

It's easy to read through a book or listen to a lecture and feel like you're following what's going on.

What I would recommend is taking some of the code examples (I assume you have them on disk somewhere), compile them and run them, then try to change them to do something different.

  • Add another subclass to a hierarchy
  • Add a method to an existing class
  • Change an algorithm that iterates forward through a collection to go backward instead.

I don't think there's any "silver bullet" book that's going to do it.

For me, what drove home what pointers meant was working in assembly, and seeing that a pointer was actually just an address, and that having a pointer didn't mean that what it pointed to was a meaningful object.


The point at which I really got pointers was coding TurboPascal on a FatMac (around 1984 or so) - which was the native Mac language at the time.

The Mac had an odd memory model whereby when allocated the address the memory was stored in a pointer on the heap, but the location of that itself was not guaranteed and instead the memory handling routines returned a pointer to the pointer - referred to as a handle. Consequently to access any part of the allocated memory it was necessary to dereference the handle twice. It took a while, but constant practice eventually drove the lesson home.

Pascal's pointer handling is easier to grasp than C++, where the syntax doesn't help the beginner. If you are really and truly stuck understanding pointers in C then your best option might be to obtain a copy a a Pascal compiler and try writing some basic pointer code in it (Pascal is near enough to C you'll get the basics in a few hours). Linked lists and the like would be a good choice. Once you're comfortable with those return to C++ and with the concepts mastered you'll find that the cliff won't look so steep.


In a sense, you can consider "pointers" to be one of the two most fundamental types in software - the other being "values" (or "data") - that exist in a huge block of uniquely-addressable memory locations. Think about it. Objects and structs etc don't really exist in memory, only values and pointers do. In fact, a pointer is a value too....the value of a memory address, which in turn contains another value....and so on.

So, in C/C++, when you declare an "int" (intA), you are defining a 32bit chunk of memory that contains a value - a number. If you then declare an "int pointer" (intB), you are defining a 32bit chunk of memory that contains the address of an int. I can assign the latter to point to the former by stating "intB = &intA", and now the 32bits of memory defined as intB, contains an address corresponding to intA's location in memory.

When you "dereference" the intB pointer, you are looking at the address stored within intB's memory, finding that location, and then looking at the value stored there (a number).

Commonly, I have encountered confusion when people lose track of exactly what it is they're dealing with as they use the "&", "*" and "->" operators - is it an address, a value or what? You just need to keep focused on the fact that memory addresses are simply locations, and that values are the binary information stored there.


Did you read Bjarne Stroustrup's The C++ Programming Language? He created C++.

The C++ FAQ Lite is also good.

John at CashCommons

For pointers and classes, here is my analogy. I'll use a deck of cards. The deck of cards has a face value and a type (9 of hearts, 4 of spades, etc.). So in our C++ like programming language of "Deck of Cards" we'll say the following:

HeartCard card = 4; // 4 of hearts!

Now, you know where the 4 of hearts is because by golly, you're holding the deck, face up in your hand, and it's at the top! So in relation to the rest of the cards, we'll just say the 4 of hearts is at BEGINNING. So, if I asked you what card is at BEGINNING, you would say, "The 4 of hearts of course!". Well, you just "pointed" me to where the card is. In our "Deck of Cards" programming language, you could just as well say the following:

HeartCard card = 4; // 4 of hearts!
print &card // the address is BEGINNING!

Now, turn your deck of cards over. The back side is now BEGINNING and you don't know what the card is. But, let's say you can make it whatever you want because you're full of magic. Let's do this in our "Deck of Cards" langauge!

HeartCard *pointerToCard = MakeMyCard( "10 of hearts" );
print pointerToCard // the value of this is BEGINNING!
print *pointerToCard // this will be 10 of hearts!

Well, MakeMyCard( "10 of hearts" ) was you doing your magic and knowing that you wanted to point to BEGINNING, making the card a 10 of hearts! You turn your card over and, voila! Now, the * may throw you off. If so, check this out:

HeartCard *pointerToCard = MakeMyCard( "10 of hearts" );
HeartCard card = 4; // 4 of hearts!
print *pointerToCard; // prints 10 of hearts
print pointerToCard; // prints BEGINNING
print card; // prints 4 of hearts
print &card; // prints END - the 4 of hearts used to be on top but we flipped over the deck!

As for classes, we've been using classes in the example by defining a type as HeartCard. We know what a HeartCard is... It's a card with a value and the type of heart! So, we've classified that as a HeartCard. Each language has a similar way of defining or "classifying" what you want, but they all share the same concept! Hope this helped...

That was a fairly lousy analogy.

This video has a great conceptual intro to classes via Java.

Lecture 4 | Programming Methodology (Stanford)


You may find this article by Joel instructive. As an aside, if you've been "working in C++ for some time" and have graduated in CS, you may have gone to a JavaSchool (I'd argue that you haven't been working in C++ at all; you've been working in C but using the C++ compiler).

Also, just to second the answers of hojou and nsanders, pointers are very fundamental to C++. If you don't understand pointers, then you don't understand the basics of C++ (acknowledging this fact is the beginning of understanding C++, by the way). Similarly, if you don't understand classes, then you don't understand the basics of C++ (or OO for that matter).

For pointers, I think drawing with boxes is a fine idea, but working in assembly is also a good idea. Any instructions that use relative addressing will get you to an understanding of what pointers are rather quickly, I think.

As for classes (and object-oriented programming more generally), I would recommend Stroustrups "The C++ Programming Language" latest edition. Not only is it the canonical C++ reference material, but it also has quite a bit of material on a lot of other things, from basic object-oriented class hierarchies and inheritance all the way up to design principles in large systems. It's a very good read (if not a little thick and terse in spots).

Ben Collins
lol, I just read that article by Joel and that's what made me come here and search for questions about pointers.
+9  A: 

Understanding Pointers in C/C++

Before one can understand how pointers work, it is necessary to understand how variables are stored and accessed in programs. Every variable has 2 parts to it - (1) the memory address where the data is stored and (2) the value of the data stored.

The memory address is often referred to as the lvalue of a variable, and the value of the data stored is referred to as the rvalue (l and r meaning left and right).

Consider the statement:

int x = 10;

Internally, the program associates a memory address with the variable x. In this case, let's assume that the program assigns x to reside at the address 1001 (not a realistic address, but chosen for simplicity). Therefore, the lvalue (memory address) of x is 1001, and the rvalue (data value) of x is 10.

The rvalue is accessed by simply using the variable “x”. In order to access the lvalue, the “address of” operator (‘&’) is needed. The expression ‘&x’ is read as "the address of x".

Expression          Value
x                   10
&x                  1001

The value stored in x can be changed at any time (e.g. x = 20), but the address of x (&x) can never be changed.

A pointer is simply a variable that can be used to modify another variable. It does this by having a memory address for its rvalue. That is, it points to another location in memory.

Creating a pointer to “x” is done as follows:

int* xptr = &x;

The “int*” tells the compiler that we are creating a pointer to an integer value. The “= &x” part tells the compiler that we are assigning the address of x to the rvalue of xptr. Thus, we are telling the compiler that xptr “points to” x.

Assuming that xptr is assigned to a memory address of 1002, then the program’s memory might look like this:

Variable    lvalue    rvalue
x           1001      10   
xptr        1002      1001

The next piece of the puzzle is the "indirection operator" (‘*’), which is used as follows:

int y = *xptr;

The indirection operator tells the program to interpret the rvalue of xptr as a memory address rather than a data value. That is, the program looks for the data value (10) stored at the address provided by xptr (1001).

Putting it all together:

Expression   Value
x                   10
&x                  1001
xptr                1001
&xptr               1002
*xptr               10

Now that the concepts have been explained, here is some code to demonstrate the power of pointers:

int x = 10;
int *xptr = &x;

printf("x = %d\n", x);
printf("&x = %d\n", &x);     
printf("xptr = %d\n", xptr);
printf("*xptr = %d\n", *xptr);

*xptr = 20;

printf("x = %d\n", x);
printf("*xptr = %d\n", *xptr);

For output you would see (Note: the memory address will be different each time):

x = 10
&x = 3537176
xptr = 3537176
*xptr = 10
x = 20
*xptr = 20

Notice how assigning a value to ‘xptr’ changed the value of ‘x’. This is because ‘xptr’ and ‘x’ refer to the same location in memory, as evidenced by ‘&x’ and ‘xptr’ having the same value.

17 of 26
thanks for the very helpful response

Pointers are not some sort of magical stuff, you're using them all the time!
When you say:

int a;

and the compiler generates storage for 'a', you're practically saying that you're declaring
an int and you want to name its memory location 'a'.

When you say:

int *a;

you're declaring a variable that can hold a memory location of an int. It's that simple. Also, don't be scared about pointer arithmetics, just always have in mind a "memory map" when you're dealing with pointers and think in terms of walking through memory addresses.

Classes in C++ are just one way of defining abstract data types. I'd suggest reading a good OOP book to understand the concept, then, if you're interested, learn how C++ compilers generate code to simulate OOP. But this knowledge will come in time, if you stick with C++ long enough :)


Graduated college and you don't understand "advanced" concepts like pointers? I thought that was 1st semester basics?


Your problem seems to be the C core in C++, not C++ itself. Get yourself the Kernighan & Richie (The C programming language). Inhale it. It's very good stuff, one of the best programming language books ever written.


In the case of classes I had three techniques that really helped me make the jump into real object oriented programming.

The first was I worked on a game project that made heavy use of classes and objects, with heavy use of generalization (kind-of or is-a relationship, ex. student is a kind of person) and composition (has-a relationship, ex. student has a student loan). Breaking apart this code took a lot of work, but really brought things into perspective.

The second thing that helped was in my System Analysis class, where I had to make UML class diagrams. These I just really found helped me understand the structure of classes in a program.

Lastly, I help tutor students at my college in programming. All I can really say about this is you learn a lot by teaching and by seeing other people's approach to a problem. Many times a student will try things that I would never have thought of, but usually make a lot of sense and they just have problems implementing their idea.

My best word of advice is it takes a lot of practice, and the more you program the better you will understand it.

Matt Pascoe