Thread: "Pointers" <-- crappy name

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.

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.

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.

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.

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

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

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"

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:

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:

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:

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

and then:

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.

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.

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".

Originally Posted by MK27

A pointer *is not* an address.

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

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?

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:

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.