[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