-2

I know that my question may be very basic, but I wonder for the objects that are getting more than one cell in memory, like arrays and user defined objects (that need more than one cell in memory and thus have the range of consecutive addresses in memory), what does a pointer really mean for this kind of objects? Is it the variable in C++ that contains the address of these objects in memory (logically not true because these objects have occupied more than one cell in memory and thus have range of consecutive addresses), or let's say pointers to these objects are just the beginning address of these objects (more rational).

Please help me understand; and if you are not convinced with my interpretation about C++ pointers definition, give me the right one.

In most C++ tutorials it said that pointers just contain the addresses of other variables in memory.

PermanentGuest
  • 5,213
  • 2
  • 27
  • 36
Infintyyy
  • 929
  • 1
  • 11
  • 23
  • possible duplicate of [Difference between pointer and pointer variable](http://stackoverflow.com/questions/17643036/difference-between-pointer-and-pointer-variable) and many others. – Joni Aug 19 '13 at 09:16
  • Yes, your 'more rational' understanding is the right one. I have no clue why people are downvoting a straightforward question whose answer won't generally be explicitely written out in basic C++ books meant for beginners. – PermanentGuest Aug 19 '13 at 09:25
  • @Joni: I don't see how that is a duplicate of the linked question? This question is about the behaviour of pointers to bigger objects/arrays, while the other one is about more basic understandig of pointers. – Grizzly Aug 19 '13 at 09:32
  • 1
    @Grizzly, I see that the question has been edited and made clearer, and I'm retracting my close-vote. – Joni Aug 19 '13 at 09:38

5 Answers5

3

Lets say you have a variable a declared and initialized like

int a = 5;

Then you create a pointer and make int point to a using the address-of operator &:

int* pointer_to_a = &a;

The actual value of the pointer_to_a is the address of where a is in memory. But the compiler knows it's a pointer, so you can use pointer_to_a to access the contents of a with the dereference operator *:

*pointer_to_a = 10;
std::cout << "a = " << a << '\n';

The above will print 10, as you set the contents of where pointer_to_a is pointing to 10.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
2

If I (as the compiler) know that an int is (on this particular system) 4 bytes long, a pointer to an int need only tell me where the "start" of the int is: I just need to read it and the next 3 bytes!

For larger data structures like arrays, the same is true: if I know where my array starts, I know that I can access each subsequent element by adding the size of one item to the address. For example, if I have an int a[] starting at address 100, and an int is 4 bytes, then

a[32] = (address of a) + (32 * size of int) = 100 + 128 = 228 So bytes 228 through 231 are the integer at a[32].

What makes this slightly easier to use is that the compiler abstracts the different sizes of the data types away for us. If I add 1 to my integer pointer, the address actually increases by 4! This is because I very rarely (almost never) want to read half an integer: it's more likely that I wish to look at a series of integers in turn.

KidneyChris
  • 857
  • 5
  • 12
1

From here

The memory of your computer can be imagined as a succession of memory cells, each one of the minimal size that computers manage (one byte). These single-byte memory cells are numbered in a consecutive way, so as, within any block of memory, every cell has the same number as the previous one plus one.

This way, each cell can be easily located in the memory because it has a unique address and all the memory cells follow a successive pattern. For example, if we are looking for cell 1776 we know that it is going to be right between cells 1775 and 1777, exactly one thousand cells after 776 and exactly one thousand cells before cell 2776.]1

Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
  • That's a rather simplistic view, and is not how the C++ standard describes it. In particular, there is not assumption that the memory cells form a succession (pointer arithmetic isn't supported between two random pointers), nor is it assumed that each cell has a unique address (and in fact on the 8086 they don't). – MSalters Aug 19 '13 at 09:23
0

This might help to imagine the memory layout of OS Here

when you specify a pointer you also specify the type pointer it will hold to e.g. int* In this case compiler will reserve 4 bytes (usually the size of int) and store the value in little-endian/big-endian format.

I think you are correct that it will have a pointer to the starting cell only and if you say p++ then compiler will increment 4 bytes and point to some other address.

If you want to refer to the next cell p is pointing to then think you might need to read the address (HEX address) and increment and deference it.

HVar
  • 120
  • 8
-1

For arrays, a pointer means exactly the same as for everything else.

A pointer points to the location of exactly one object (in reply to unwind's pointer-to-array objection: this one object may also be an array), no more no less. It does not know the size of an array-of-objects if there is one (and doesn't care).1
It is perfectly possible to create a pointer to a single value and access it as an array of some size, although that is neither well-defined nor wise (it will probably crash). It is also perfectly possible to use a pointer to an array of size 5 and access the 10th element. Again, this doesn't make sense and will probably crash, but nothing prevents you from doing it (except with compiletime-constant indices, at least some compilers may warn). The pointer does not know.

For a structure, a pointer knows the structure's location in memory, no more and no less. On top of that, the compiler knows additional details such as the offset of members to this base address. This information is however bound to the type that you use to dereference the pointer (not to the pointer itself!).
It is therefore generally possible to access a Car object through a Banana pointer, if you get your Banana to point at a car (by cast, by accident, or by arithmetic). Of course that doesn't make any sense, but it's possible. The pointer does not know a difference, and the compiler will act "as if".

1 Yes, if it's a pointer-to-array, the compiler knows the size of that array. But that only matters for type correctness. You'll get a compile error trying to assign an array-of-5 to a pointer-to-array-of-4, because they're different things. But that is irrespective of the pointer. The pointer still does not know the size of the array, and it still does not know whether there is one array or an array-of-arrays. You can still use it either way (probably to desastrous effect), and there is no logic that prevents you from doing harm.
Damon
  • 67,688
  • 20
  • 135
  • 185
  • -1, the compiler generally cares a great deal about the size of pointed-to objects (hence why pointer arithmetic works the way it does). – unwind Aug 19 '13 at 09:12
  • @unwind: The compiler cares a) about the type, giving a compile error if need be, and b) about the size of _one_ element, the one that is pointed to. It does not "care" or enforce anything else. How would you otherwise be able to access an array out of bounds? Also, the allocator obviously cares about the size of the block it allocated, but that's irrespective of the question - the pointer does not know or care. – Damon Aug 19 '13 at 09:14
  • Sure, but "one element" might be, for instance, an array. See [this question's top answer](http://stackoverflow.com/questions/859634/c-pointer-to-array-array-of-pointers-disambiguation) for instance. See [this brief example](http://ideone.com/otA6RY), too. You make it sound as if pointers to arrays don't exist, but perhaps I'm just not reading your answer right. – unwind Aug 19 '13 at 09:18
  • @unwind: Of course pointers to arrays exist, heh :) But the pointer doesn't know, not really anyway. In the example that you linked, the pointer to an array-of-8 integers does not know whether it points to _one_ array-of-8 integers (which is just one object of "some type", and apart from the compiler enforcing types does not matter), or whether it maybe points to an array-of-5 of arrays-of-8 integers. And, in principle, you could legally assign it to a plain normal `int*` which doesn't even know about the first array. It only knows about one integer, the first element in the array-of-8 object. – Damon Aug 19 '13 at 09:31
  • I don't understand what "knowing" means. Of course the pointer itself in memory doesn't contain any information about the type it points to, but that doesn't mean much since it also (for instance) doesn't contain information saying it's a pointer. It's all in the types associated with the bits, by the compiler. – unwind Aug 19 '13 at 09:33
  • @unwind: The "doesn't contain information saying it's a pointer" assumption is not entirely correct. On x86 and ARM that's certainly the case, but it's not necessarily so. Not every bit pattern passes as a valid pointer on all architectures. Insofar, a pointer at least possibly "knows" that it is a pointer. But it doesn't know what comes before or after the object it points to (another object in an array, a different variable, unallocated memory, or dragons?). Still, the compiler will happily create code to access whatever is there, if asked to, _as if_ there was something of that type. – Damon Aug 19 '13 at 09:54