Re: Well defined meaning of pointer to an array
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.
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++.
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 a completely different thing than a structure.
Not in this respect.
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
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.
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.
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.
And he's less sloppy here with his terminology here than in
the glossary you cited before;-)
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.
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.
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. 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.
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.
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.
... 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.
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.
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de