Re: Well defined meaning of pointer to an array
"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:91bid8Fq8tU1@mid.uni-berlin.de...
Paul <pchristor@yahoo.co.uk> wrote:
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.
No, you don't because your premise that an array is a pointer
is not correct.
I'm not premising that an array is a pointer, but I am acknowledging that it
it like a pointer in many ways.
An array identifier is not an object that contains elements , it's a pointer
like object that points to the array.
An array is not a single object, its a sequence of objects.
An array is a single object that consists of objects, the
same as a structure or a class. Have you ever asked yourself
how something can have a type (and you have agreed that there
is an array type) but not be an object? That would make it
the only beast with such a strange property in all of C++.
No I disagree with this completely. There is no containing object with an
array.
An array is a sequence of objects, the array-type object is a pointer-like
object that references the array.
Arrays are no different at all from
structures (or other type of objects) in that respect. Apply the
'&' operator to an object and you get a pointer to that object.
An array is not a structure, its a sequence of objects of the same type.
The object type is for example with an array of chars:
char arr[64];
The object type is char. The identifier 'arr' is a pointer like object that
references an array of char objects.
If you take the address of 'arr' you are creating a pointer that points to
'arr', not to the array of chars.
char* p = ("An array of chars");
char** pp = &p;
char arr[] = ("An array of chars");
char (*parr)[18] = &arr;
parr is the same level of indirection as pp. The only difference is that
parr is a different type of pointer.
Both pointers need to be dereferenced twice to access the array of chars.
An array is a completely different thing than a structure.
Not in this respect
There are so many differences I don't even know where to start.
Applying the subscript operator is identical to dereferencing.
No, it isn't. It "opens up" the box that is an array object
and extracts the value of the indexed element. Dereferencing
only comes into it if the compiler exppamds the '[]' operator
into
No the array object is simply converted to a pointer. The array object is
not a class like container it's a pointer-like object
arr[ i ] <-> * ( arr + i )
And I have already tried to explain as clearly as I can
what steps the compiler is going through with that:
That you think that you could "dereference an array" is
exactly the point were you are confused due to the "array
decays to a pointer to the first element of the array in
certain situations". I already see you screeming: "but
arr[ i ] = * ( arr + i )
and proves my point". But in reality things are different:
the compiler starts with the 'a+i' bit. Now it says to it-
self "I got two values to add. But the left one is nothing
I know how to get a value for, that looks badly wrong. But
stop, is this an array object? Well, in that case I have this
strange rule that when I need a value but find an array I'm
supposed to replace it by a pointer to the first element of
the array. Ok let's try that. Wow, now I have a pointer and
I know how to add an integer to a pointer, I've got to ad-
vance the address by as many bytes as the product of the
number and the size of what the pointer is pointing to. Fine,
that gives me another pointer." And then, in the next step
it does the dereferencing, arriving at the value of arr[i].
The somewhat special relationship (but which doesn't imply
identity) of pointers and arrays is only due to the special
way arrays are handled in C++ (and C) when they appear in a
context where the compiler needs a value.
You seem to be replying to yourself here.
No, arrays can't be passed by by value. Structures can, but arrays
can't. If you think that's wrong please show some exapmle code of
how it's to be done.
Its simple:
void foo(int arg1, int arg2, int arg3){
int arr[] = {arg1, arg2, arg3};
}
int arr1[3] = {1,2,3};
foo(arr1[0],arr1[1], arr1[2]);
I hope you're not serious. This has nothing to do with pas-
sing arrays by value. You pass three ints to a function
and then stick them into a new array in that function. There
is abosultely no passed of an array at all here, neither by
value nor by reference.
It passes the array values to the function.
It doesn't matter how it does it, it just does do it.
And if you don't believe me you perhaps should consider
taking a look at one of the books by Stroustrup. E.g. in
"The C++ Programming Language (3rd edition)" he writes
in section "7.2.1 Array Arguments" (p. 147):
If an array is used as a function argument, a pointer
to it's initial element is passed. [...] That is, an
argument of type T[] will be converted to a T* when
passed as an argument. [...] In other words, arrays
differ from other types in that an array is not (and
can not be) passed by value.
You have made one good point here, that arrays differ from other types.
And he's less sloppy here with his terminology here than in
the glossary you cited before;-)
I wouldn't say he is sloppy at all,
How come it needs to be dereferenced twice to access an array of objects?
Dereference it once and you get a memory address.
int arr1[3] = {1,2,3};
int (*p)[3] = &arr1;
std::cout<< *p <<std::endl;
std::cout<<**p;
In both cases you rely on the implicit conversion of an
array object into a pointer to its first element. If you
want to print out '*p' the compiler is looking for a value
but what it finds instead is an array object (the result
of '*p'). And that is then implicitely converted to a poin-
ter to the first element of the array object. So '*p' is
not a pointer, it is actively converted from an array ob=
ject to a pointer in this situation.
Its converted to a string. The output is a string representation of a memory
address.
*p certainly does not access the array of integers, but **p does.
p is a pointer to an object that references the array, it's not a pointer to
the array of integers.
Same for the '**p' case. '*p' results is an array object,
but the compiler needs a pointer value that it can derefe-
rence. And again "the rule" kicks is, '*p' is converted
to a pointer that in turn can be dereferenced.
If you're talking of "under the hood" then this implicit
conversion of array objects to pointers is what happens
"under the hood", nothing else.
The object pointed to is an object that references the array, however you
choose to think of it. Taking the address of an array-type object creates a
pointer to the array-type object, not to the array of int objects.
An array-type object is a pointer under the hood.
Saying the same thing again and again doesn't make it
true - an array isn't a pointer, neither directly nor
under any hoods. An array is an object.
An array is not a single object , its a sequence of objects. Obviously
unless it is size one.
That it consists
of a collection other objects, all of the same type, is
secondary - a specific property characterizing that type
of objects. A pointer, in contrast, is an object that just
contains an address, typically that of another object.
An array is not a single addressable object comparable to a class type, it's
a sequence of objects.
For example you cannot do this:
int arr1[3];
int arr2[3];
arr1= arr2;
With an array this is not possible because you cannot access the array as a
whole. With a class type object this is perfectly doable:
struct obj_type{int x, y, z;};
obj_type a,b;
a=b;
The pointer-type does not define what is pointed to. The object, or
array
of objectsd allocated defines what is pointed to , not a pointer that
points to it.
If you use a pointer in an expression then the pointer alone
determines the type of what is pointed to. You'd need casts to
get around that.
It doesn't
int* p =0;
p does not point to an integer type object.
That's immaterial. You can make a pointer point anywhere
in memory. But the hour of thruth has come when you try
to dereferencing it. For a 0 pointer you'll get a segmen-
tation fault, because the computer will try to fetch an int
value from a memory location you have no permission to access.
If it points to a more reasonable place the compiler will re-
trieve an int from that location. The type of pointer (and
nothing else) determines what kind of value the computer
will try to fetch from the location pointed to. If you in-
crement or decrement a pointer or add some integer value
the resulting address is again determined by the type of
the pointer. Same for the subtraction of two pointers.
Yes but this proves that a pointer-type does not define what it points to
So when you said:
"If you use a pointer in an expression then the pointer alone determines the
type of what is pointed to."
You were incorrect.
Im not confusing anything, that is how it works.
I beg to disagree;-)
Its impossible to address the array as a whole. You can only address
one
element at a time.
Wrong. Apply your argument to a structure or class and you
will immediately realize that this is non-sense.
What does a class have to do with it? A class is not an array.
You seem to think a class is the same as an array, this is very wrong.
With respect to being a (composite) object that has an
address there's no difference. And that was what I was
refering out.
No a class type object is not the same as an array.
... And yes, I agree that "1+1=2" (at least in
all nunber systems except binary). The problem is that you claim
"1=0" and then draw conclusions from that which, of course,
are then as wrong as the premise you started from;-)
I do not claim that 1=0, whatever that is supposed to mean :-)
I was alluding to your claim that an array is a pointer (which
you now somewhat retracted by qualifying it with "under the
hood", but that doesn't make too much of a difference) If you
start with that premise you can derive without any logical
flaws all kinds of further wrong statements.
I never did say "an array is a pointer." in the context you imply.
I have said that an array is a pointer under the hood, because in many
situations that is how it works.
Perhaps you could try to clearly describe what "under the
hood" means. It's a term you introduced without specifying
what it actually means. Since you're obviously as interested
as I am in getting at the bootom of what really is going on
when one uses arrays and what's their relationship to pointers
it would be interesting to see, for both of us, what that hood
thing is actually doing. I have explained, I think quite
detailed, how I consider things to be working (the "under the
hood" thing being nothing more than the implicit conversion of
arrays to pointers to their initial element under certain cir-
cumstances), so it would be interesting to see what's happening
"under the hood" from your point of view. Perhaps that leads us
to a point where we can apply Ocam's razor, i.e. picking the
simpler of two explanation that still explains all observable
effects.
"under the hood" means the way a compiler treats an array as a pointer, at
slightest opportunity