Re: Well defined meaning of pointer to an array
"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:91btcpF9smU1@mid.uni-berlin.de...
Paul <pchristor@yahoo.co.uk> wrote:
"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.
I have no doubt that you seem to believe that. But that doesn't
make it a fact.
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.
There, of course, is no containing object, the array *is* the
containing object. And, again, how can be there a type without
an object that has this type? Are you avoiding the hard ques-
tions?;-)
What you say makes no sense re: "there is no containing the object, the
array is the containing object."
I'm avoiding nothing.
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.
Both are objects that contain other objects. And that's what
counts.
No there is no array container object. Its a pointer like object that
references the array, not a containing object.
The object type is for example with an array of chars:
char arr[64];
The object type is char.
We've been further. You had accepted that 'arr' is of type
array-of-(some)-chars. Now it's up to you to explain why you
retract something that you already admitted to.
The identifier 'arr' is a pointer like object that
references an array of char objects.
You always use weasel-words like "under-the-hood" or "pointer-
like" object. But programming is all about being exact. So
define your terminology or discussions are meaningless.
If you take the address of 'arr' you are creating a pointer that points
to
'arr', not to the array of chars.
Of course, taking the address of 'arr' results in a value
(not a pointer yet, since that's an object) that is the
address of 'arr'. But the "not to the array of chars" bit
has me stymied. We have an array of chars, called 'arr',
when we take its address we get a pointer that points to
'arr', but then that pointer does not point to that array?
Where does it point to then, if I may ask?
It points to arr, not to the array of chars, that arr references.
char* p = ("An array of chars");
No reason for the parenthesis here. And the type on the left
side object should actually be a const char pointer since you
are not allowed to change what 'p' points to afterwards.
So, you have an (immutable) array object on the right side.
And you try to assign that to a char pointer. The compiler
will notice that there's something isn't right (array object
on the left, pointer on the right), but again "the rule" ("If
I need a pointer but got an array I'm supposed to try to con-
vert the array to the first element of that array") kicks in
and safes the day.
char** pp = &p;
No problem here at all, 'p' is a pointer to char, so
putting a '&' in front of it gives you a pointer-to-
pointer-to-char.
char arr[] = ("An array of chars");
char (*parr)[18] = &arr;
Mostly fine (modulo const-ness), 'parr' is a genuine pointer
to an object of type 'array-of-18-chars'.
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.
But the difference in types is what this is all about.
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.
An airplane is something completely different from a car. But
in one respect, getting you from A to B, they share something.
And there are lots of comparisons between airplanes and cars
when it comes to their advantages/disadvantages when going
from A to B, even though they are rather different things,
aren't there? So, obviously, some aspects similar can be com-
pared, putting aside all other differences that don't matter?
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:
<quite a bit of text snipped to avoid posting it thrice>
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.
I just wanted to make you read what I wrote;-) If you did
you didn't show any signs that you did.
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.
I was always completely honest with you that arrays are some-
what special. I told you about their "second-class" role in
C++ and C, I told you how they are get some special treatment
etc. So were's your point?
You haven't told me anything , many of the things you say have been
completely incorrect and I have had to correct much of what you say.
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.
That's what happens after things have been handed over to
the std::cout class. Do you really want me to go also into
that as well?
I just told you what happens, its converted to a string. You are starting
to become a bit of an arse.
*p certainly does not access the array of integers, but **p does.
Please stop throwing words around. Define what "access"
means. Otherwise I could start arguing with "safda" does
"ewori" and none of use would be wiser.
Yeah I was right you are becoming a total arse now.
p is a pointer to an object that references the array,
it's not a pointer to the array of integers.
What is the difference in your language between "references"
and "pointing"? 'p' to me is a pointer to the array object
with the name 'arr'. And that's all there is about it. Now
stop hiding behind lots of undefined terms and tell me
exactly what else it is. Or are you a politician?
I'm hiding behind nothing, if you don't understand a simple term like
"references" you must be a bit stupid.
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.
Sorry, what is referencing what and what's pointing to what?
This more and more sounds like a talk show were someone
doesn't want to admit something got f*cked up and uses lots
of verbiage to hide behind it.
If you cannot understand these simple terms then I conclude you are too
stupid to commumnicate at this level.
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.
And what made you think that this is the case?
Beccause that is the case.
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;
You can't do that for exactly the same reasons you can't do
struct S {
int x;
double y;
};
int s.x = 6;
double s.y = 3.15;
Before you can set the members of a structure you need a struct
object. Before you can set the elements of an array you need an
array object.
There is no comparison between a struct an an array they are two completely
different entities.
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;
That already has been discussed to death. Yes, arrays are
"second-class" citizens in that respect. Go back in this
thread and see that I pointed out exactly this and tried
to give an explanation why, for historical reasons, this
happened (it was just yesterday). If you want to argue about
that feel free to do so, but don't try to use things I already
explained. I hope you can do better or it's going to become
boring.
So what is this array object that contains the array elements that you speak
off?
There is no such object, there is only the array elements themselves.
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.
Sorry, "you were incorrect" isn't an argument, it's nothing more
than an unsubstantiated claim. I'm hope you can do alot better
than that.
Its not a claim , what you said is completely incorrect.
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.
Of course, a class type object is not the same as an array
(object). Where did I claim this? But they're both objects
and they both have an address (the lowest addres in memory
theu occupy).
<quote ref="A few messages ago">
"> A structure is a differnet beast altogether because we can create a
pointer
to a struct, as a whole.
And that's simply and plainly wrong. A structure (or class)
is no different from an array in this respect at all."
</quote>
An array is not a single object its an *drumroll* array of objects.
If you dont understand that perhaps you will understand the term it is a
contiguous sequence of objects.
There is no containing object that contains the array elements. An array is
accessed by dereferencing a pointer, oh wait you don't understand the term
accessed do you. Ok if you cannot understand. I cannot communicate with you.
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
Sorry, I'm not really impressed.
I'm not particularly bothered if you are impressed or not.
Could you perhaps become a bit
more forthcoming about the "way a compiler treats an array as a
pointer, at slightest opportunity"? I've tried to explain to you
what I think the compiler is exactly doing each step along the way,
and getting back some mumblings about "what the compiler is doing",
with "slightest opportunity" thrown in, isn't very enlightening.
What is it doing under what circumstances in your POV? If we know
that we can have a meaningful discussion. I think we're quite a
bit past the hand-waving stage of an argument, so let's get down
to the nitty-gritty details.
I think if you cannot understand terms like "accessing an array" and
"referencing an array" then you are maybe not intelligent enough for a
conversation at this level.