"Pointers" <-- crappy name

I just had a thought today I wanted to share. There are a million and 1 "tutorials" out there that try to explain pointers.. like they are difficult to understand. The only thing difficult to understand about them, is why they are called "pointers" when they are more like "maps".

Heres my pointer tutorial:

Every location in memory has a hexidecimal address. when you want to share your variable with another function, you send it that hexidecimal address, so it knows where to put the value. If you want to see the address, you use the '&' sign. If you want to see the value, you use the '*' sign.

And thats what a "pointer" is.. er.. basically. ;)

just a thought.

> is why they are called "pointers" when they are more like "maps".
Not really, a map has a different meaning.

Plus "maps" don't support arithmetic.

> Every location in memory has a hexidecimal address
Sure, Hexadecimal, Octal, Binary, Decimal, or however you wish to interpret it. More often than not they're stored in binary ;).

You explained references in a way, more than you did pointers. :-)

Well, it's not only C that calls a pointer a pointer. Pascal (and Modula-2/3) as well as their ancestors Algol and related Simula. Intel assembler also uses the form "byte ptr [eax]"

So whilst it may seem illogical to you, it is common in a lot of computer programming at several levels.

Techncially, addresses aren't hex numbers. Hex is just a simpler way of describing the value of an address in a way that can be trasnslated to binary. An address is simply a number - internally stored as binary, but so is all integers, and you wouldn't say "integers are actually hexadecimal values", would you?

--
Mats

Quote:

---

Originally Posted by argv

Heres my pointer tutorial:

Every location in memory has a hexidecimal address. when you want to share your variable with another function, you send it that hexidecimal address, so it knows where to put the value. If you want to see the address, you use the '&' sign. If you want to see the value, you use the '*' sign.

---

Reasonably concise explanation, except that:

• Hexadecimal is just a common representation for addresses so you should leave it out or comment as such.
• You assume that the reader knows the context with which you talk about the address of and indirection operators.
• You say nothing about pointer arithmetic and one past the end pointers.
• You say nothing about null pointers and null pointer constants.

Hmmm. I often have problems with "doctrine" but I would say pointer is a picture perfect word.

A pointer is a value stored in memory. The value of the pointer is a (presumably different) address. If we met on the sidewalk, and you said "Where is the Masonic Lodge?", I would say "over there" and point to it.

As for drawing a map, hopefully that will not be necessary ;)

OP's got it all figured out. Should have submitted to C++ 0x, now we have to live forever with the archaic "pointer" nomenclature.


I think a less usefull name is RAII (Resource Aquisition is Initialization). Basically it goes like this

1. Tell someone to use RAII
2. Said someone asks what that stands for
3. Word out the Acronym
4. Person asks what that means
5. Explain to them the meaning
6. Be told, "That's a silly name for it".

But then I see how Bjarne names his variables and functions and it all makes sense.

I've never understood the issues that people have with pointers. Perhaps its because a lot of books out there do a terrible job of explaining them or try to explain them in a simple fashion which ends up not being simple at all.

Pointers, IMO, are one of the most powerful and therefore one of the most dangerous and most abused features of C/C++. And while other languages are rushing to remove them C++ is just trying to make them a bit smarter. I prefer the latter.

I would say other (managed) languages trying to build on the idea of smart pointers.

Quote:

---

I would say other (managed) languages trying to build on the idea of smart pointers.

---

Many of them have completely removed them by making everything a pointer under the hood but never exposing them to the programmer. If they provided the programmer with a choice of whether to use a smart pointer or not use a pointer at all that would be much different.

If there's a box on the shelf, and I say "Without moving, or saying anything, where's the box?" What do you do? Point to it. Pointer is the perfect name, because that's all it actually does. It simply points to where something is in memory.

"Where's this variable located?" *points*


Quzah.

Just think of int* as a completely different type than int, just like char is different than int ;) a int* stores adress', just like int stores non decimals, or how they are calls...
So int a = 5; is valid, just as much as char a = 'a' is valid, and as much as int* = 0x344546 is valid, then the difference between char*, int*, double*, ect. is that this '0x450688' (some random adress) has to be the adress to one of the types which people consider them as... Like, int* has to be such a value (0x4546757) and it has to hold the address of a integer, same with every other type, char*, double* ... Now you all know how to explain it to noobs like me , so start preaching! >: D ( NOTE: I FAIL at explaining :S )

int* = 0x344546 is invalid in C++, but valid in C.
The concept of pointers is simple, but when you start adding things together, it starts to get confusing.

Quote:

---

int* = 0x344546 is invalid in C++, but valid in C.

---

Lack of identifier aside, that's not valid C. It's just accepted by most C compilers because legacy C code is horrible.

Quote:

---

Originally Posted by matsp

Well, it's not only C that calls a pointer a pointer. Pascal (and Modula-2/3) as well as their ancestors Algol and related Simula. Intel assembler also uses the form "byte ptr [eax]"

So whilst it may seem illogical to you, it is common in a lot of computer programming at several levels.

Techncially, addresses aren't hex numbers. Hex is just a simpler way of describing the value of an address in a way that can be trasnslated to binary. An address is simply a number - internally stored as binary, but so is all integers, and you wouldn't say "integers are actually hexadecimal values", would you?

--
Mats

---

You could, but it wouldn't make sense. Mostly I just think alot of confusion from beginning people (like myself) is the term "pointers" because.. really.. does it "point" to anything, or is just an address send to a function to tell that function where to store it's value?

As everyone here knows, to a computer any value of any sort is simply a combination of "on" or "off", 1 or 0, whatever. octal, hex, and the like are used (from what I understand) because values get so big, that doing everything in binary would be much less efficient, and as technology grows, so does capacitance. Therefore it is ALL binary, just in different form.

Quote:

---

Originally Posted by quzah

If there's a box on the shelf, and I say "Without moving, or saying anything, where's the box?" What do you do? Point to it. Pointer is the perfect name, because that's all it actually does. It simply points to where something is in memory.

"Where's this variable located?" *points*


Quzah.

---

what if I said "wheres minnesota?" :) Just kidding, but really, my point is (no pun intended) that for a beginner who knows nothing about the concept of passing information by value or by address, I would think a simple explaination that a "pointer" is nothing more than the address where a variable is stored. That makes sense to me, but so many books and 'tutorials' and whatever do a horrible job of explaining what a pointer is. They try to show you code, etc etc..

I just wish that when I first started working with C, someone had just said "Ok, a pointer is simply a memory address." Ok, thats simple. So, I'm passing an address. Awesome. I love the concept of pointers, just not the explaination of them.

Quote:

---

Originally Posted by argv

what if I said "wheres minnesota?" :) Just kidding, but really, my point is (no pun intended) that for a beginner who knows nothing about the concept of passing information by value or by address, I would think a simple explaination that a "pointer" is nothing more than the address where a variable is stored. That makes sense to me, but so many books and 'tutorials' and whatever do a horrible job of explaining what a pointer is. They try to show you code, etc etc..

---

I've tried using an explanation similar to yours. It doesn't help much. The question is not what a pointer IS (most people can understand that part) but why you would need one.

And there's nothing special about hexadecimal. An address is an address, whether you express it in binary, decimal, hex, or encode it into a sonata using no instances of the musical note 'E'

Quote:

---

Originally Posted by argv

Mostly I just think alot of confusion from beginning people (like myself) is the term "pointers" because.. really.. does it "point" to anything, or is just an address send to a function to tell that function where to store it's value?

---

The last phrase is correct, but the "or is" is sort of non-sensical, like "is the sky really blue, or is it just the color of oxygen in the atmosphere?". The sky is blue, the color of oxygen in the atmosphere. A pointer is an address sent to a function that points to where a value is stored.

Going back to the street metaphor, and the Original Post, a map would be something of an area. If I wrote "123 Elm St." down on a piece of paper and gave it to you, you would not call it a map. And in fact map is a term in programming you will discover later, and it involves regions of memory.

Some (non-compiled) languages use something called a reference which is functionally identical to a pointer. The only word I have heard that might be more descriptive than "pointer" is "reference". On the other hand, pointer is a more unique word than "reference" -- it is not so overloaded semantically. So once you get the concept, pointer is probably more convenient, immediately recognizable, and less likely to be confused with something else. Maybe "referer" would be good if you do not have to say it five times fast ;)

Quote:

---

That makes sense to me, but so many books and 'tutorials' and whatever do a horrible job of explaining what a pointer is.

---

I agree 100% on that. But it is not because of the name; it is because of the strong elliptical tradition in programming "instructional" discourse, which is virtually the de facto standard. You could call it anything, it will not improve the quality of the material to which you refer.

Quote:

---

Originally Posted by brewbuck

The question is not what a pointer IS (most people can understand that part) but why you would need one.

---

Bravo brewbuck. That's the rub.

Quote:

---

Originally Posted by MK27

Some (non-compiled) languages use something called a reference which is functionally identical to a pointer. The only word I have heard that might be more descriptive than "pointer" is "reference". On the other hand, pointer is a more unique word than "reference" -- it is not so overloaded semantically. So once you get the concept, pointer is probably more convenient, immediately recognizable, and less likely to be confused with something else.

---

Reference is the concept, pointer is the implementation. The fact that a pointer is an address enables a lot of syntax you wouldn't have otherwise -- subtraction of pointers, incrementing and decrementing, testing for NULL, etc.

References I think are more confusing, because often they automagically dereference themselves, which is hard to explain. And they need not be implemented in terms of addresses, so it's difficult to talk about what a reference is actually "made of" other than saying it's just some sort of magic object that stands for some other object.

People have trouble with abstraction. Some people can't even grasp why functions are important. I'm not surprised that a lot of people can't figure out pointers, but what bothers me is the claim that pointers are intrinsically difficult to understand.

They aren't. What's hard to understand is why on Earth you'd need one.

Quote:

---

Originally Posted by laserlight

Reasonably concise explanation, except that:

• Hexadecimal is just a common representation for addresses so you should leave it out or comment as such.
• You assume that the reader knows the context with which you talk about the address of and indirection operators.
• You say nothing about pointer arithmetic and one past the end pointers.
• You say nothing about null pointers and null pointer constants.

---

No I did not. My main point really, is that most explainations of pointers really suck. The concept is not hard to get, I guess it's just who gives it to you. I'm very glad that I have a good teacher who does a really good job of explaining and driving home the concept.

Still, I maintain that, from my understanding at least, it all boils down to the fact that a "pointer" is simply an address. Like if you wanna find someones house.. you use their address.. if you want to store a value created by another function, you use it's address. That just seems, to me, a better approach to the understanding of pointers.. but, maybe I'm wrong, since I learned how to do arithmetic with hexidecimal numbers before I learned what the heck a pointer was.. ??

Quote:

---

Originally Posted by argv

Still, I maintain that, from my understanding at least, it all boils down to the fact that a "pointer" is simply an address. Like if you wanna find someones house.. you use their address.. if you want to store a value created by another function, you use it's address. That just seems, to me, a better approach to the understanding of pointers.. but, maybe I'm wrong, since I learned how to do arithmetic with hexidecimal numbers before I learned what the heck a pointer was.. ??

---

I still have no idea why you think hexadecimal has anything to do with pointers.

Quote:

---

Originally Posted by brewbuck

Reference is the concept, pointer is the implementation. The fact that a pointer is an address enables a lot of syntax you wouldn't have otherwise -- subtraction of pointers, incrementing and decrementing, testing for NULL, etc.

References I think are more confusing, because often they automagically dereference themselves, which is hard to explain. And they need not be implemented in terms of addresses, so it's difficult to talk about what a reference is actually "made of" other than saying it's just some sort of magic object that stands for some other object.

People have trouble with abstraction. Some people can't even grasp why functions are important. I'm not surprised that a lot of people can't figure out pointers, but what bothers me is the claim that pointers are intrinsically difficult to understand.

They aren't. What's hard to understand is why on Earth you'd need one.

---

There are alot of things that are used just to make code more organized and readable. Like using #define for anything besides a macro. I like the idea of pointers, because I like the idea that I can create something in one spot, and then if I want another function to be able to change that value based on some sort of (whatever), then it can. Thats the magic I guess.

It's not a huge deal to me, I'm not going to stand on the sidewalk preaching about how much I don't care for the term "pointer", I'm really just fueling conversation and debate I suppose. If I had to name it something, I would just call it an address. albeit, an address you can do math with, have a null value for, and whatever since it's not a text string, but an actual value.

Quote:

---

Originally Posted by brewbuck

I still have no idea why you think hexadecimal has anything to do with pointers.

---

The hexidecimal thing really is just because thats what it is on *my* system, and thats what it shows up as when I'm in debug. It's ALL binary. I'm not saying that it's always a hexidecimal or octal, or binary anything. But it's an address, otherwise known as a combination of bits that represent a real value of some sort.

Quote:

---

Originally Posted by argv

Still, I maintain that, from my understanding at least, it all boils down to the fact that a "pointer" is simply an address. Like if you wanna find someones house.. you use their address.. if you want to store a value created by another function, you use it's address. That just seems, to me, a better approach to the understanding of pointers.. but, maybe I'm wrong, since I learned how to do arithmetic with hexidecimal numbers before I learned what the heck a pointer was.. ??

---

There is a slight complication. A pointer contains an address (or, that is what it's value should be) but a pointer also has an address of it's own, where it's value is stored. The later is generally irrelevant, but this distinguishes the concept of "memory address" from "pointer".

Pointer arithmetic generally does not involve hex. Eg, to move thru a string:

Code:

---

#include <stdio.h>

int main() {
        char string[]="hello world", *ptr=string;
        int i;
        while (ptr[0] != '\0') {
                printf("%c",ptr[0]);
                ptr++;
        }
        return 0;
}

---

Hex is just a form of notation. ++ is 1, which is 1 in dec and hex. If you wanted to skip to the end of string, you could use +=0xb, but most people would use +=11. Hex is used alot with mem address because the numbers are big and (possibly) because most programmers will recognize a hex number as a memory address (but that is not the only place it is used).

Quote:

---

Originally Posted by brewbuck

I've tried using an explanation similar to yours. It doesn't help much. The question is not what a pointer IS (most people can understand that part) but why you would need one.

And there's nothing special about hexadecimal. An address is an address, whether you express it in binary, decimal, hex, or encode it into a sonata using no instances of the musical note 'E'

---

You could probably write many programs without using a single pointer. From what i've been told or read, pointers are more about increasing performance than about being something necessary. "Don't pass a copy of the whole structure, just pass the address" is, I suppose, the idea there.

Of course, a programs gotta be pretty big before you have to worry about that much.

Quote:

---

Originally Posted by brewbuck

References I think are more confusing, because often they automagically dereference themselves, which is hard to explain. And they need not be implemented in terms of addresses, so it's difficult to talk about what a reference is actually "made of" other than saying it's just some sort of magic object that stands for some other object.

---

As someone who learned perl and C nearly concurrently, I would say the two slightly different concepts shed a lot of light on each other -- probably because the reference is not implemented as an address. The concept of "reference" is pure pragmatism. I remember feeling that very clearly. Of course, I am now ashamed to admit it took me longer than 5 minutes to completely grasp either ;)

Programming is magic, IMO. You could say a function "is a magical thing", a memory address "is a magical thing", etc, etc. Even with a knowledge of transistors and logic gates, I doubt anyone really conceptualizes all the way down to "reality" very often when writing code.

I know that I have no idea how an instruction decoder works. So I can't get down to transistors. But I think the really useful knowledge ends at the micro architecture level.

Quote:

---

Originally Posted by argv

You could probably write many programs without using a single pointer.

---

As long as they are just about ints. Remember:

Code:

---

char string[]="hello world";
printf("%p",string);

---

Technically, "string" is a pointer. However, there are slightly more restrictions on it vis. applying pointer arithmetic (not allowed!).

Quote:

---

Originally Posted by MK27

The last phrase is correct, but the "or is" is sort of non-sensical, like "is the sky really blue, or is it just the color of oxygen in the atmosphere?". The sky is blue, the color of oxygen in the atmosphere. A pointer is an address sent to a function that points to where a value is stored.

Going back to the street metaphor, and the Original Post, a map would be something of an area. If I wrote "123 Elm St." down on a piece of paper and gave it to you, you would not call it a map. And in fact map is a term in programming you will discover later, and it involves regions of memory.

Some (non-compiled) languages use something called a reference which is functionally identical to a pointer. The only word I have heard that might be more descriptive than "pointer" is "reference". On the other hand, pointer is a more unique word than "reference" -- it is not so overloaded semantically. So once you get the concept, pointer is probably more convenient, immediately recognizable, and less likely to be confused with something else. Maybe "referer" would be good if you do not have to say it five times fast ;)


I agree 100% on that. But it is not because of the name; it is because of the strong elliptical tradition in programming "instructional" discourse, which is virtually the de facto standard. You could call it anything, it will not improve the quality of the material to which you refer.


Bravo brewbuck. That's the rub.

---

well, thats all I'm sayin really. :) (about the bad explainations)

Quote:

---

Originally Posted by MK27

As someone who learned perl and C nearly concurrently, I would say the two slightly different concepts shed a lot of light on each other -- probably because the reference is not implemented as an address. The concept of "reference" is pure pragmatism. I remember feeling that very clearly. Of course, I am now ashamed to admit it took me longer than 5 minutes to completely grasp either ;)

Programming is magic, IMO. You could say a function "is a magical thing", a memory address "is a magical thing", etc, etc. Even with a knowledge of transistors and logic gates, I doubt anyone really conceptualizes all the way down to "reality" very often when writing code.

---

No, probably not, but it might help. When determining how to write a program, I usually just as myself "how can I write it in a way that asks as few questions as possible." From the computers standpoint, well, it doesn't care. It'll do whatever, in order. The very concept of the computer or how computers came to be isn't magic. We needed a math machine because humans are not precise enough and prone to many mistakes. Back in the day, a human was called a "computer" if they computed stuff all day.

I'm just thankful we got past the Babbage math machine. As much fun as that looked to be. ;)

Quote:

---

Technically, "string" is a pointer.

---

No, it isn't. string is an array. Which is not the same thing as a pointer.

Quote:

---

Originally Posted by CornedBee

No, it isn't. string is an array. Which is not the same thing as a pointer.

---

Okay. It was my understanding that "string" points to the starting address of the array*. But since the complier guarantees the memory is sequential, I suppose that is silly.

Still:

Code:

---

#include <stdio.h>

int main() {
        char string[]="hello world", *ptr=string;
        printf("%p %p\n",string,ptr);
        printf("%p %p\n",&string,&ptr);
        return 0;
}

---

You know what happens here. So string is just the starting address of an array, whereas ptr has it's own, separate address containing the address of string? That would explain why no arthmetic with "string" is possible.

I think I just answered my own question. Thanks for clarifying, CornedBee.

* I'm sure I picked that up from the cboard crew too, but I won't point fingers..wha-wha

No, string is an array of allocates bytes in which the string is stored. It's not a pointer.
This is why it can be modified, while string literals cannot (because they are not stored in a buffer on the stack like the array is).
Just as the compiler says, the size of string is 12 bytes (if I counted correctly) and ptr is 4/8 bytes.

string is an array.

Now, C has the distinction between "lvalue" and "rvalue". These are muddled concepts, but succinctly put, the lvalue of a variable is the variable itself (think of it as a "location value"), while the rvalue is its value. Temporaries and literals don't have lvalues (except string literals). You cannot take the address of an rvalue. You cannot use an lvalue in most other operations, such as arithmetic.
Whenever lvalues are used where rvalues are required, you get an implicit conversion. For most things, this conversion has no practical effect; it's only a matter of arguing about the theory of the language. But for functions and arrays, it has an effect: a function is converted to a pointer to it, and an array is converted to a pointer to its first element.

Learning things again today. So I can't go "string++" because "string" is an lvalue. And yet, I can dereference (*string) and get an rvalue...it seems to me there is a slight anomaly in the syntax since "*ptr++" and "ptr++" accomplish the exact same thing.

Quote:

---

Originally Posted by CornedBee

Temporaries and literals

---

What do you mean by "temporaries"?

If I write std::string() then I have created a temporary of type std::string. If I call a function that returns a std::string, that return value is a temporary. If I pass a string literal to a function that takes a const reference to a string, that reference will reference a temporary.

There's lots of places in C++ where temporary objects are created implicitly or explicitly. Such objects are rvalues.

Quote:

---

Originally Posted by MK27

There is a slight complication. A pointer contains an address (or, that is what it's value should be) but a pointer also has an address of it's own, where it's value is stored. The later is generally irrelevant, but this distinguishes the concept of "memory address" from "pointer".

Pointer arithmetic generally does not involve hex. Eg, to move thru a string:

Code:

---

#include <stdio.h>

int main() {
        char string[]="hello world", *ptr=string;
        int i;
        while (ptr[0] != '\0') {
                printf("%c",ptr[0]);
                ptr++;
        }
        return 0;
}

---

Hex is just a form of notation. ++ is 1, which is 1 in dec and hex. If you wanted to skip to the end of string, you could use +=0xb, but most people would use +=11. Hex is used alot with mem address because the numbers are big and (possibly) because most programmers will recognize a hex number as a memory address (but that is not the only place it is used).

---

well, I still have much to learn about the lower levels of the language, and advanced pointer operations. I still think the term "pointer" is a misnomer and misleading. But then again, I haven't gotten as far as most here, so I'll just wait till after my advanced C class, but for now, to me, pointer or array is basically synonymous with "a memory address".

Ok, well, back to my program.. I've procrastinated enough. :)

Quote:

---

Originally Posted by MK27

Okay. It was my understanding that "string" points to the starting address of the array*. But since the complier guarantees the memory is sequential, I suppose that is silly.

Still:

Code:

---

#include <stdio.h>

int main() {
        char string[]="hello world", *ptr=string;
        printf("%p %p\n",string,ptr);
        printf("%p %p\n",&string,&ptr);
        return 0;
}

---

You know what happens here. So string is just the starting address of an array, whereas ptr has it's own, separate address containing the address of string? That would explain why no arthmetic with "string" is possible.

I think I just answered my own question. Thanks for clarifying, CornedBee.

* I'm sure I picked that up from the cboard crew too, but I won't point fingers..wha-wha

---

Still, that's undefined behaviour. That is, the way you print the addresses. No-one said sizeof(void *) == sizeof(char *) :-). Considering %p is for void pointers.

Quote:

---

Originally Posted by zacs7

Still, that's undefined behaviour. That is, the way you print the addresses. No-one said sizeof(void *) == sizeof(char *) :-). Considering %p is for void pointers.

---

Even if different types of pointers are different sizes (or are different in even stranger ways), you can still convert from any pointer type to void *.

So it's just a matter of adding an explicit cast to the pointer when you call printf(). A smart compiler might even do that for you, although of course you should never rely on that.

Quote:

---

No-one said sizeof(void *) == sizeof(char *)

---

The C++ standard does, in 3.9.2p4:
"A cv-qualified or cv-unqualified (3.9.3) void* shall have the same representation and alignment requirements as a cv-qualified or cv-unqualified char*."

> So it's just a matter of adding an explicit cast to the pointer when you call printf(). A smart compiler might even do that for you, although of course you should never rely on that.
That was my point ;)

Quote:

---

Originally Posted by CornedBee

The C++ standard does, in 3.9.2p4:
"A cv-qualified or cv-unqualified (3.9.3) void* shall have the same representation and alignment requirements as a cv-qualified or cv-unqualified char*."

---

Oh cool... perhaps I chose the wrong example type then... Although I did gloss over the C99 draft. But you did quote the C++ standard ;)

Quote:

---

Originally Posted by argv

My main point really, is that most explainations of pointers really suck.

---

Then you should not claim that your explanation is a "tutorial" ;)

Quote:

---

Still, I maintain that, from my understanding at least, it all boils down to the fact that a "pointer" is simply an address.

---

Yes, but what tutorial on pointers does not say this?

Here are the first few sentences of section 10.1.1 of Accelerated C++ by Koenig and Moo:

Quote:

---

A pointer is a value that represents an address of an object. Every distinct object has a unique address, which denotes the part of the computer's memory that contains the object. If you can access an object, you can obtain its address, and vice versa. For example, if x is an object, then &x is the address of that object, and if p is the address of an object, then *p is the object itself. The & in &x is an address operator, and is distinct from the use of & to define reference types. The * is a dereference operator, which works analogously to the way * works when applied to any other iterator. If p contains the address of x, we also say that p is a pointer that points to x.

---

Then Koenig and Moo go on to talk about null pointers. Since they cover iterators first, they have already covered one past the end iterators. Of course, we could always talk about pointers before generalising to iterators.

Here is a statement from cprogramming.com's own pointer tutorial:

Quote:

---

In the computer, pointers are just variables that store memory addresses, usually the addresses of other variables.

---

Oh, and another tutorial pretty high on the search results for "C++ programming" is cplusplus.com's tutorial, which first introduces the idea of memory and memory locations, then the concept of a reference:

Quote:

---

The address that locates a variable within memory is what we call a reference to that variable.

---

and then:

Quote:

---

The variable that stores the reference to another variable (...) is what we call a pointer.

---

So, it sounds that you are just complaining about sloppy reading material that is not worth bothering about in the first place. Get a good book and cross reference with good tutorials.

Quote:

---

Originally Posted by argv

but for now, to me, pointer or array is basically synonymous with "a memory address".

---

In many contexts, an array is converted to a pointer to its first element, but that does not make an array a pointer. Perhaps the easiest way to demonstrate this is to take the sizeof an array and compare it to the sizeof a pointer. If you get the same result, change the number of elements of the array and compare again.

Quote:

---

Originally Posted by laserlight

Yes, but what tutorial on pointers does not say this?

---

A pointer *is not* an address. A pointer contains an address, and it has an address of it's own. That's two addresses for every pointer. The purpose of a pointer is to point to an address. It is not itself the address. I think you do go on to explain that, which makes it even stranger why you would concurr "a pointer is an address".

Quote:

---

Originally Posted by MK27

A pointer *is not* an address.

---

The term "pointer" can also be used to mean "address".

Quote:

---

Originally Posted by laserlight

The term "pointer" can also be used to mean "address".

---

Yes, and to refer to a species of weird looking dogs. But I bet you can't actually write a sentence doing what you just claimed.

The [pointer/address] of variable x is...

The [pointer/address] is 0xdeadbeef.

The [pointer/address] should advance through the string one byte at a time.

Maybe that last one will work either way, but I think then it will have two slightly different meanings. And we have been witnessing the effect this apparently has on the uninitiated, at least one of whom evidently feels that since "a pointer is an address" why call it a pointer?

Quote:

---

Originally Posted by MK27

But I bet you can't actually write a sentence doing what you just claimed.

---

Koenig and Moo did that in the paragraph that I quoted: "if p is the address of an object, then *p is the object itself". Obviously, we can also say: if p is a pointer to an object, then *p is the object itself.

This website's tutorial is more explicit about defining terms:

Quote:

---

A note about terms: the word pointer can refer either to a memory address itself, or to a variable that stores a memory address. Usually, the distinction isn't really that important: if you pass a pointer variable into a function, you're passing the value stored in the pointer--the memory address.

---

This usage can also be seen as something of a simplification in terms, e.g., we may talk about an int variable n being 2 when it is more accurate to talk about the value of n being 2, so it may be more convenient to use "pointer" and "address" interchangeably when the distinction is not significant.

Which takes us back to:

Quote:

---

Originally Posted by argv

so many books and 'tutorials' and whatever do a horrible job of explaining what a pointer is.

---

And I completely agree. Because I now understand what a pointer is, the Koenig and Moo statement makes sense (pointlessly). If I did not know, I doubt very much that it were serve to clarify the matter. At all.

One day in the distant future maybe I will write a book for beginner's on C. I can totally remember going through material and thinking I'd like to, because much of the material is so bad. I honestly believe the standard of technical writing on CS and programming is a often a low one. This may be similar to other academic fields which suffer from a lack of original sources for material and must depend on a slightly inbred circus of "my teacher wrote the textbook I am required to pay for".

In turn, the style of this low standard is taken up by people who prepare tutorials, etc, and gradually disseminates itself into acceptability. Once you know the language, it obviously easy to defend a piece of work by saying, "Well, the code is not wrong" or even "the code is good" and opinions on the kind of discourse you site above will be "subjective". What they are saying may be true, but it is almost semantic obfuscation masquerading as an "explanation".

It's easy to describe things. But it's hard to explain things.

Most people just say "the for loop iterates over each element in a sequence." Why use a for-loop? What is a sequence? What is iteration. These are implicitly books for programmers. Most often for C or Java programmers. But the required knowledge is almost never written anywhere.

Quote:

---

Originally Posted by Brafil

But the required knowledge is almost never written anywhere.

---

Yes! This what I meant by

Quote:

---

Originally Posted by MK27

it is not because of the name; it is because of the strong elliptical tradition in programming "instructional" discourse, which is virtually the de facto standard. You could call it anything, it will not improve the quality of the material to which you refer.

---

Maybe the idea is to *hack* your way into understanding.

Ok, but what really gets me is how people always call dimetrodons dinosaurs. They are even included in children's plastic dinosaur sets. In actually they are synapsids. Go figure......

Quote:

---

Originally Posted by MK27

Which takes us back to:



And I completely agree. Because I now understand what a pointer is, the Koenig and Moo statement makes sense (pointlessly). If I did not know, I doubt very much that it were serve to clarify the matter. At all.

One day in the distant future maybe I will write a book for beginner's on C. I can totally remember going through material and thinking I'd like to, because much of the material is so bad. I honestly believe the standard of technical writing on CS and programming is a often a low one. This may be similar to other academic fields which suffer from a lack of original sources for material and must depend on a slightly inbred circus of "my teacher wrote the textbook I am required to pay for".

In turn, the style of this low standard is taken up by people who prepare tutorials, etc, and gradually disseminates itself into acceptability. Once you know the language, it obviously easy to defend a piece of work by saying, "Well, the code is not wrong" or even "the code is good" and opinions on the kind of discourse you site above will be "subjective". What they are saying may be true, but it is almost semantic obfuscation masquerading as an "explanation".

---

The best thing I've learned is that if you want to learn something, learn it from someone who knows how to teach things. I.e. if a book is used in a college class, it's probably a good book to have on the shelf.

Quote:

---

Originally Posted by argv

The best thing I've learned is that if you want to learn something, learn it from someone who knows how to teach things. I.e. if a book is used in a college class, it's probably a good book to have on the shelf.

---

Generally true, although we have seen a few examples here where there is a university lecturer with bigger ego than educational skill that writes a book and then uses that for the education in the school. Not always such a good thing.

--
Mats

Some bogus statements:

Quote:

---

No, string is an array of allocates bytes in which the string is stored.

---

This is a recursive definition. "A string is something in which the string is stored". I like the following definition: a string is a null-terminated array of chars. This way, we avoid talking about memory, bytes, allocation and so on.

Quote:

---

A pointer is a value stored in memory.

---

Certainly not. Consider the following code:

Code:

---

int x = 17;

---

Now 17 is a value stored in memory. Is it a pointer? No.



Here's my definition of a pointer. But let's first define variables: a variable is a 4-tuple consisting of name, size, address and value.

Now it's easy to define pointers: a pointer is a variable whose value is an address.


Pointers are not addresses, and addresses are not pointers: it doesn't make sense to ask for the address of an address, the size of an address or the name of an address. For pointers, these questions are easily answered. But for the sake of simplicity, we may sloppily call pointers "addresses" and vice versa if the context doesn't require further distinction.

Greets,
Philip

A pointer can be a value stored in memory (or in swap space or in a register).

A pointer is a variable whose value is an address in memory. This graph shows you the contents of "pointer".

Code:

---

    +----------------+
    |  0x3f93f84e  |      ------------------------->    Memory location at 0x3f93f84e
    +----------------+

        int *pointer;

---

Then programmers say that pointer "points to" the thing that is at memory address 0x3f93f84e.

If you say *pointer, you mean you wanna access whatever is at memory location at 0x3f93f84e. Since you meant pointer to be a pointer to _int_ (int *pointer is a * (pointer) to int), the computer fetches an _int_eger from memory location 0x3f93f84e.

Code:

---

    +----------------+
    |  0x3f93f84e  |      ------------------------->  Segmentation Fault
    +----------------+

  printf("%d\n", *pointer);

---

What happened? That's strange! But the solution is easy. The pointer is uninitialized. That means, it's value is undefined (probably not what you want). Since the space where pointer is stored (pointers are also stored in memory) has probably been used before, it will contain some crap left from other programs or your own program. This crap is 0x3f93f84e. The computer doesn't know that, it makes just what you want - in this case, it fetches an integer from somewhere in you memory.

BUT - That's a security risk. What if 0x3f93f84e points to operating system data or *where your passwords are stored in*? Then any hacker can get into your computer by accessing anything he wants. He makes the pointer "point to" somewhere he wants, for example where your login name and password are stored. Then he accesses that location. Voila, he has you name and password, if they are not encrypted (don't worry about this part).

Or say, you want to modify *pointer. You could write zeros there where your operating system's heart is beating. That would immediately crash your computer. Either you didn't want this to happen, or a hacker wanted to kill your session. Too late. You've lost your 1000 line program cuz you didn't save.

To prevent this from happening, the operating system doesn't allow you to look at position 0x3f93f84e in memory. It neither allows you to write there. For your own security. That's, PAY ATTENTION where you pointers point to.

Code:

---

    +----------------+                                  +----------------+
    |  0xac398ef4  |      ------------------------->  |  0x00000000  |
    +----------------+                                  +----------------+
 
        pointer = &i;                                        int i = 0;

---

Now you say, "make pointer point to i", or "gimme the address of i and save it in pointer". The '&' operator takes the address of something, for example i. It returns 0xac398ef4 in this case, which is the memory location where i is saved in. So the value of pointer is the address of i.

(Of course, we have assigned i to zero, that means in fact we have written all zeros into the location where i resides)

Now, let's take a look at i. We could simply write "printf("%d\n", i)". But that's boring! We wanna learn something. Ok, let's try to use pointer. Remembered the part with the Segmentation Fault? Try again!

Code:

---

    +----------------+                                  +----------------+
    |  0xac398ef4  |      ------------------------->  |  0x00000000  |
    +----------------+                                  +----------------+
 
  printf("%d\n", *pointer);                                        i

---

Compile... Run... YESSS! No strange errors, just plain zero. i was zero, remember? Now we get the same zero! What happened? We wanted to fetch an integer from memory location 0xac398ef4. Now we know that we can read from there, cuz it's *our* memory and nobody else can read from there except we can. We own i, so we own 0xac398ef4 where i is stored. Congrats, for you own some memory now!

But what if we want to put a 5 into i? "i = 5;", right? BOORING! We can do it like that:

Code:

---

    +----------------+                                  +----------------+
    |  0xac398ef4  |      ------------------------->  |  0x00000005  |
    +----------------+                                  +----------------+

      *pointer = 5;                                              i

---

Now we say "write a 5 wherever pointer points to!". Since pointer points to i, we write 5 into i. Now, test i:

Code:

---

    +----------------+                                  +----------------+
    |  0xac398ef4  |      ------------------------->  |  0x00000005  |
    +----------------+                                  +----------------+

  printf("%d\n", *pointer);                                        i

---

Compile... Run. What do we see? We printed out *pointer first remember?, that gave us a zero. Now, we write a 5 into the location where i lives. Now, we print out i... The output is... 5! Wow! Cool, huh? If we print *pointer again, we'll get another 5. If you assign i to 293, *pointer will give you 293. It's just always the same number.

That was the basics. Anyone who doesn't understand can tell me. Don't be ashamed, I'm sure probably _nobody_ here knew it since s/he was a baby. But once you get it, you know very much. Pointers are one of the REAL powers of C.

Quote:

---

Originally Posted by Snafuist

I like the following definition: a string is a null-terminated array of chars. This way, we avoid talking about memory, bytes, allocation and so on.

---

The official definition is: "a string is a contiguous sequence of characters terminated by and including the first null character." This is more accurate since a string might only occupy part of an array.

These are definitions for C-style strings. There is no requirement on std::string to be null-terminated, for example, yet it still is a string.

More generally, a string is a contiguous sequence of characters. Not necessarily contiguous in memory (sgi's rope isn't, nor are typical strings in functional languages), just in concept - a string has no holes.

Quote:

---

Originally Posted by CornedBee

These are definitions for C-style strings.

---

Yes, hence "official" in this context means "as defined by the C standard".

Quote:

---

Originally Posted by Snafuist

Code:

---

int x = 17;

---

Now 17 is a value stored in memory. Is it a pointer? No.

---

That's some bad logic you're doing there. You disprove "A -> B" by giving an example where A = false and B = true. But "A -> B" still holds there.

Like:
C is a programming language.
Now you disprove this saying: Java is a programming language. Is it C? No.

That said, a pointer doesn't have to be a value stored in memory. It can be stored in a register (or on a piece of paper for that matter).

Quote:

---

Originally Posted by Brafil

BUT - That's a security risk. What if 0x3f93f84e points to operating system data or *where your passwords are stored in*? Then any hacker can get into your computer by accessing anything he wants. He makes the pointer "point to" somewhere he wants, for example where your login name and password are stored. Then he accesses that location. Voila, he has you name and password, if they are not encrypted (don't worry about this part).

---

My instructor once blew the bounds of an array and wrote to the part of the computer that tells the computer to write to random parts of the hard drive

Wow. The computer shouldn't be writing to random parts of the hard drive. So you mean your instructor rescued it?

Quote:

---

Originally Posted by ಠ_ಠ

My instructor once blew the bounds of an array and wrote to the part of the computer that tells the computer to write to random parts of the hard drive

---

On any modern operating system, that is impossible.
But it is possible to overwrite other sensitive data by writing out of bounds (it might even have corrupted a buffer that holds contents to write to the disk in an open file).

Quote:

---

Originally Posted by Elysia

On any modern operating system, that is impossible.
But it is possible to overwrite other sensitive data by writing out of bounds (it might even have corrupted a buffer that holds contents to write to the disk in an open file).

---

It was quite a long time ago

Quote:

---

Originally Posted by ಠ_ಠ

It was quite a long time ago

---

Recently, my mom sprayed one of those disinfectant/air freshener things on her new Mac laptop keyboard while it was running. Ha ha ha ha....

I can see that people here have different opinions of what exactly a pointer is, even though at the same time I assume they are able to use them properly.

Maybe one could clear up confusion by learning some basic assembly language, where you learn how "pointers" truly work. I quoted pointer, because pointer can refer to the abstract idea (ie, reference variable) or to the physical operations that take place to implement that idea.

At the bit level, then, a 32-bit "integer" differs not at all from a 32-bit "pointer." It's just a finite series of bits. The difference is in how the CPU will interpret that "number." We, the programmers, tell the CPU how to do that by specifying different opcodes.

One opcode says "store the bits at some memory location at some other memory location" (x = y in C) and another says "go to this memory address and interpret the bits at that memory address as another memory address and copy those to some other memory location" (x = *y in C)

Now, you all may or may not have known that already, but I think it covers the basics of pointers. Now one just has to learn the C syntax behind it all.

Quote:

---

Originally Posted by CornedBee

string is an array.

Now, C has the distinction between "lvalue" and "rvalue". These are muddled concepts, but succinctly put, the lvalue of a variable is the variable itself (think of it as a "location value"), while the rvalue is its value. Temporaries and literals don't have lvalues (except string literals). You cannot take the address of an rvalue. You cannot use an lvalue in most other operations, such as arithmetic.

---

C99's compound literals are lvalues and you can take the address of them. For example:

Code:

---

int *ip = &(int){ 5 };

---

Quote:

---

Originally Posted by argv

"pointers" when they are more like "maps".

---

A map is more like an array of pointers than just a pointer. You still need another pointer to use a map say like "1600 Pennsylvania Avenue NW in Washington, D.C.". That address isn't the pointer but this post now becomes a pointer to a place on the map that points to a place on the planet.

I prefer to think of it like the sign on the bathroom door. You wouldn't ........ on the sign would you? It's saying that a toilet is inside. Pointers are just really common knowledge. We follow road signs, elevator buttons, and just all sorts of things every day.

IMO your tutorial has just confused more people who already knew what a pointer was, but just didn't know how to use them in programming.

Just cause someone says something is hard doesn't mean it's hard. Pointer IMO are just to hyped up and that has caused more confusion than was nessacary.