[Tutor] pointer puzzlement

Dave Angel davea at davea.name
Sat May 9 00:54:58 CEST 2015


On 05/08/2015 06:26 PM, Alan Gauld wrote:
> On 08/05/15 19:10, Jim Mooney Py3.4.3winXP wrote:
>> On 7 May 2015 at 18:42, Dave Angel <davea at davea.name> wrote:
>>
>>> Python doesn't have pointers
>>
>>
>> So what is the difference between a python name and a pointer?
>
> OK, This could get deepo.
> Lets start with the supoerficial...
>
> A pointer (in most languiages) is a named alias for a memory address.
> That is a name that is a specidic memory location. At least in C and
> some other languages.
>
> That means you can, in C , declare a variable (say p) to be a pointer
> to some array of objects and it is simply the memory address of the
> first object in the array. The second objects address is therefore
> p+sizeof(o) where 'o' is the object type of the array.
>
> You can in fact write code like this in C (and frequently do):
>
> int p*;  // declare p to be a pointer to an integer
> int ia[] = {1,2,3,4,5,6,7,8,9,0};  // an array of 10 integers
> p = ia;   # p holds the address in ia, ie its first element

This is a shorthand for
     p = & (ia[0])

>
> printf("%d\n", p);  // print the object, ie ia[0]

   print("%d\n", *p)   // print the first object   ia[0]
   print(("%d\n", p[0]);  // print the first object, ie ia[0]

> printf("%d",p+3);   // print the 4th object ie ia[3]

   printf("%d",*(p+3));   // print the 4th object ie ia[3]
   printf("%d",p[3]);   // print the 4th object ie ia[3]

and p[274] is a random pile of bits which might or might not happen to 
be readable.  Using it might read some other int, it might read a few 
bytes of code, it might cause a segmentation fault.

>
> So p is a pointer to an integer. And an array is a sequence
> of integers in memory so you can access subsequent memory
> locations by adding numbers to p. (The compiler multiplies
> the number by the size of the type of p to get the actual
> memory address.)

And all this is part of the language specification.  C is after all, an 
overblown assembly language, and all processors are expected to emulate 
the appropriate Dec machine.


>
> In other languages (eg Pascal) pointers are slightly more
> abstract but not much. They are more like C++ references
> than memory addresses, but the end result is much the same:
> they are very tightly  tied to the physical concepts of
> memory versus variables.
>
> Now in contrast...
> In Python a name is a much more abstract concept and is
> just a label that is attached to an object. How the label
> gets attached is an entirely abstract and implementation
> specific concept. In practice its usually via a dictionary
> so that a variable is a name which is a key of a dictionary.
> The corresponding value is an object or, (crucially) maybe
> a pointer to an object. But the name is not the pointer
> it's the corresponding value that (may be) a pointer.
>
> So this Python code (compare to the C above) makes no sense:
>
> aList = [1,2,3,4,5,6,7,8,9,0]
> print aList_+ 3
>
> aList is not a pointer to the start of a sequence of
> objects in memory. aList is a key to a dictionary
> that holds a reference to a list of objects. And adding
> 3 to a key in a dictionary is not a sensible operation.

I'd maintain that this is still more than what the language guarantees. 
  The model I have of the language is that a name is a key in some 
namespace (but not necessarily a dict).  The value that's associated 
with that key is an abstraction that the interpreter knows how to decode 
to identify one particular object.  It might be a pointer, it might be 
an integer, it might be a pair of values.

The object might have a fixed location, or it might move around.  As 
long as at any moment that the code is running, the interpreter can find 
the object, it doesn't matter.

-- 
DaveA


More information about the Tutor mailing list