I am trying to sort an array with a pointer. This is what I have so far. This is pretty much the example ripped form the textbook, though the example in the text does not include
std::copy(net, net+SIZE, net2);
void pointer(void) {
int j,i;
std::copy(net, net+SIZE, net2);
//int *p[SIZE];
float temp;
int sortedflag=0;
//for (i=0;i<SIZE;i++) net2[i]=net+i;
for(i=0;i<SIZE;i++)cout<<*net2[i]<<"";
while (!sortedflag){
sortedflag=1;
for(j=0;j<SIZE-1;j++){
if(*net2[j]>*net2[j+i]){
temp=net2[j];
net2[j]=net2[j+1];
net2[j+1]=temp;
sortedflag=0;
}
}
}
full code
http://pastebin.com/rYYp3vrR
the error I keep getting is
cannot convert float to *float
I understand why this is but I am completely lost as to a solution. I have been searching the web for the past week for solutions.
Also Bonus points if you can explain practical uses for pointers. This is almost certainly inexperience but it just seems like pointers make the program needlessly complex and less secure.
float temp should read float *temp - you need to temporarily store a pointer, not a float.
You are right, there is little point in using pointers in this example. Suppose you were trying to sort objects that were extremely large; shuffling the objects would then take a lot more time than shuffling pointers to them.
There are lots of uses of pointers (ideally of the smart kind -shared_ptr, unique_ptr etc). It is often said, only partly in jest, that there is no problem in computer science that can't be solved with another level of indirection, and pointers are one way of achieving that indirection.
To elaborate on Alan's comments of shuffling, take for example a sorting algorithm like Merge Sort.
Generally, merge sorting uses a copy of the array that you're sorting to help in the merge process. But with pointers, e.g. a linked list implementation, you can merge sort all of your data without having to bring it into the memory that your program (process) uses.
Or, take for example moving a file on your computer. Your file system (more than likely) only changes the pointer to that file on your HDD, it won't physically move it.
(I know this is not a direct programming example, but hopefully it gives more clarity to the idea of pointers as a whole since it is a huge aspect of understanding programming.)
I don't have the requisite points to comment, so I hope you'll forgive this post listed as an answer.
I don't understand the need for dynamic arrays. From what I understand so far, dynamic arrays are needed because one cannot always tell what size of array will be needed at runtime.
But surely one can do this?:
cin >> SIZE;
int a[SIZE];
So what's the big deal with dynamic arrays and the new operator?
Firstly, that is a compiler extension and not Standard C++. Secondly, that array is allocated on the stack, whereas operator new allocates from the heap, which are two very different places that drastically affects the lifetime of the array. What use is that code if I want to return that array? Thirdly, what are you gonna do if you want to resize it?
SIZE is a variable which means it's value can be modified. Array by definition, can neither grow nor shrink in it's size. So, it's size needs to be a compile time constant.
cin >> SIZE; int a[SIZE];
Some of my users have a hard enough time using a mouse, and you want them to tell my application how much memory to allocate?
Dynamic arrays are very handy ... suppose you keep generating objects, and you have no idea how many objects might be generated (i.e., how much input might you get from someone typing an answer at a prompt, or from a network socket, etc.)? You'd either have to make predictions on what appropriate sizes are needed, or you're going to have to code hard-limits. Both are a pain and in the case of hard-limits on arrays, can lead to allocating way too much memory for the job at hand in order to try and cover every possible circumstance that could be encountered. Even then you could incur buffer-overruns which create security holes and/or crashes. Having the ability for an object to dynamically allocate new memory, yet keep the association between objects so that you have constant-time access (rather than linear-time access like you'd get with a linked-list), is a very, very handy tool.
In the early days of C, space was made on the stack when you first entered a function and the size of the stack was untouched until you called another function or returned. This is why all variables needed to be declared at the top of a function, and why array sizes needed to be known at compile-time, so the compiler could reserve a known amount of stack.
While C++ loosened the restrictions of variable declaration, it still kept the restriction of knowing the stack requirements at compile time. I don't know why.
As noted in the link in the comments, C finally allowed for dynamic size arrays. This came after C and C++ were split, so C++ didn't automatically gain that capability. It's not uncommon to find it supported as an extension in C++.
Personally I prefer:
std::cin >> size;
std::vector a(size);
Later, as others have mentioned, you could do something like ...
std::cin >> size;
a.resize(size);
...but, and this is probably the key point, you don't have to if you don't want to. If your requirements and constraints are such that they can be satisfied with static size arrays / vectors / other data structures then great. Please don't think you know enough about everybody else's requirements and constraints to remove from them a very useful tool.
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.
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.
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.
So:
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.
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.
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.
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:
create a linked list
iterate through it from start to finish
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.
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.
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!
To understand pointers, I can't recommend the K&R book highly enough.
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
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
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.
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.
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...
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 http://www.agilemodeling.com/artifacts/classDiagram.htm">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.
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.
There's no substitute 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 best book I've read on these topics is Thinking in C++ by Bruce Eckel. You can download it for free here.
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)
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.
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.
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.
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.
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.
Did you read Bjarne Stroustrup's The C++ Programming Language? He created C++.
The C++ FAQ Lite is also good.
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).
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 declaringan 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 :)
Your problem seems to be the C core in C++, not C++ itself. Get yourself the Kernighan & Ritchie (The C Programming Language). Inhale it. It's very good stuff, one of the best programming language books ever written.