Re: Well defined meaning of pointer to an array
"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:91b0toFs8fU1@mid.uni-berlin.de...
Paul <pchristor@yahoo.co.uk> wrote:
"Jens Thoms Toerring" <jt@toerring.de> wrote in message
news:9190a4F3a3U1@mid.uni-berlin.de...
Paul <pchristor@yahoo.co.uk> wrote:
When we have a pointer to something that pointer, when dereferenced,
must
access whatever it points to.
I have no big trouble with that sentence (I would prefer something
else for "access", like "when dereferenced you get the object poin-
ted to" but I guess I get the meaning and we can agree).
Well what would you prefer?
You don't always GET the object pointed to , often when dereferencing a
pointer you are allocating.
I think "accessing" the memory is as good as is gets for terminoloogy.
Another acceptable term is referencing , which is often avoided because
of
the clash with a C++ reference type object.
An array of chars when accessed must access a char, you cannot access
the
whole array of chars in one operation , unless it is very small.
Now things get hairy. What means "An array of chars when accessed
must access a char." Since it's immediately following the first
sentence I guess it was meant to be "An array of chars when derefe-
renced must access a char". Is that what you meant?
What I mean is....If you reference an array of T's you can only reference
a
T type object. For example you cannot technically reference 500 T's,
it''s
simply impossible with todays computers.
I guess you mean the term "referencing" as meaning the opposite
of "dereferencing", i.e. as applying the '&' operator to get an
objects address. And, with todays computers (and those from lots
of years back) you can "reference" (in the sense of "taking" the
address") all kinds of objects, be it simple objects like POD,
structures, arrays or classes - even functions!
Applying the & operator is called pointer derivation.
When you apply the address operator to an array-type object, you are
bascially taking the address of a pointer.
If you can do
struct S {
int a[ 500 ];
double b[ 1000 ];
} s;
S *sp = s;
why should it be impossible to do
int ( *ip )[ 500 ] = &s.a;
An array is not a single object, its a sequence of objects.
&s.a creates a pointer, that is bascially a pointer to a pointer.
It doesn't point to 500 ints' it points to another pointer object.
Now you have a nice simple pointer named 'ip' that points to an
array of 500 int elements.
No it points to a pointer object.
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.
An array is an array objects, the type of an array of ints is an int for
example:
int arr[64];
This is an array of int objects, it does not have some fancy type like
It's an array of 64 int objects. If you call that fancy or not
is your choice. And a pointer to that compoud object is pointer-
to-array-of-64-ints.
its an array of integer objects, and a pointer to these integer objects is
of type int*
int(*)[64], this pointer-type is simply a pointer with a extra level of
indirection.
It's a pointer of type pointer-to-array-of-64-ints. If you
dereference it you get back the whole array object.
No you don't , you get an address
You cannot get any pointer that address 500 ints, its techincally
impossible.
To then
get at the inidvidual array elements you need to apply the
'[]' operator. You don't "dereference an array" to get at
it's elements, you apply the '[]' operator.
Applying the subscript operator is identical to dereferencing.
And dereferencing a pointer type
int(*)[64] does not access any array elements whether you dereference it
with subscripts or asterix.
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',
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].
Otherwise there's no difference to e.g. a structure pointer.
With
struct S {
int i;
} s;
S *sp = s;
's' has type struct-S, 'sp' is pointer-to-struct-S. To get at
the structure object you have to dereference 'sp' and then to
get at the element use the '.' operator, i.e. '(*sp).i'. That
with structure pointers you can also use the fancy '->' ope-
rator, that does two seperate things at once is irrelevant,
it's just syntactic sugar and we could live with it if it
never had been invented. So, do you call that also an "extra
level of indirection"?
Compare that to structures that, as far as I know, were introduced
much later. You can copy structures using '=', you can pass and
return them from functions like any other object (except functions
and arrays). So they have a "value".
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.
The reason behind this early design decision probably was that
computers tended to have only small amounts of memory back in
the time when C was developed. And arrays tend to hold rather
large amounts of data. Thus you avoided to copy arrays anyway.
And passing an array to a function (or back from it) by value
would have required a copy each time, something that no-one in
his right mind would have done anyway.
It still the same , even with a quantum computer , I think , touching on
debatable shit now with quantum computers in your garden shed.
I have no idea how quantum computers come into this, and I don't
have one in my garden shed, already due to the non-existentence
of "my garden";-)
AN array is a sequnce of objects , you cannot have a pointer to say 500
int
objects.
The pointer to the array is of type int because when dereferenced it
accessess one object within the array.
Its totally fuckin impossible to have a pointer to the array that , when
dereferenced, accesses the whole array in a oner.
Claiming the same wrong thing several times unfortunately doesn't
make it true, even if you use swear words. You can a have pointer
to all kinds of objects, arrays being just one of them.
A pointer to an array-type object is not the same as a pointer to an array
of objects.
Now, since an array can't be passed by value it must be passed by
reference. Unfortunately, the syntax for pointers to array objects
is a bit awkward. Without the "decaying" rule the only way to pass
an array (by reference) would have been something like this:
Well an array can be passed by value but its unrealistic if the array is
say
500 objects or so.
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]);
#include <stdio.h>
This is old C, I dont remember this kinda stuff but I try to follow your
code without having to refernece stuff.
standard input/output is what it means to me .
Yes, replace it with
#include <iostream>
and it's plain, valid, legal C++.
void f( int ( *ap )[ ] )
{
printf( "%d\n", ( *ap )[ 3 ] );
}
int main( void )
{
int a[ 5 ] = { 1, 2, 3, 4, 5 };
f( &a );
Ok you pass the address of an array to a function, What is the address of
an
array? It is basically a pointer to a pointer. Why do you need to take
the
address of an array, when an array is an address already?
No, it is *not* a pointer to a pointer because arrays *are not*
pointers. Pointers points to some memory address, arrays are the
collection of memory that contains their elements. It's the same
difference as between a house number and the house itself.
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;
return 0;
}
While this is perfectly legal C it definitely isn't what you'd want
to see in a language each time you have to pass an array to a func-
tion.
When you pass an array as a pointer you must understand the
array-to-pointer
conversion.
An array is basically a pointer, but in C++ we have soem additional type
info, so its an array-type.
No, an array isn't basically a pointer. And it's exactly the same
in C and C++.
An array-type object is a pointer under the hood.
The compiler outputs a pointer compatable with the implementation, the rest
is just compiler food.
If you have an arreay of ints, the type of the array is int, the
array-type
is some C++ pointer -type.
And thus someone clever came up with the idea of the "decaying"
arrays in value context: whenever an array object is found where a
value is needed (e.g. when used as an argument to a function,) the
compiler automatically converts it to a pointer to the first element
of that array and passes this as the value to the function - instead
of throwing a tantrum that an array has no value and thus can't be
passed to the function.
No , Nobody clever came up with this idea. This is simply how computers
access memory.
The clever people have no choice, an array of ints cannot be some fancy
type
that addresses say 500 ints. An array of ints can only ever address one
single int.
If you do not address an int then you are not addresing the array of
ints.
Sorry, but you're simply deeply confused. You make a wrong
assumption ("an array is a pointer") and necessarily end up
with lots on non-sense.
No I'm not saying "an array is a pointer".
I'm saying an array is bascially a pointer under the hood, which is
completely different.
Again: an array is an object that contains (not points to!)
other objects.
No it's not, an array is a sequence of objects, there is no containing
object.
A pointer to an array points to this array
object. You don't have the same confusion about e.g. struc-
tures, where the situation is identical, so apply what you
know and understand well about structures to arrays and
you're there.
No you've got it all wrong.
There is no array object that contains other objects, an array object is
just a pointer with some additional typeinfo used by the compiler.
You can have a pointer to an array-type that doesn't even point to an
array,
for example:
int (*p)[45] =0;
This pointer points to (excuse the french ) fuck all.
I don't give a fuck what type it is, what it points to is exactly fuck
all.
That's a statement that's true for all pointers. You can make
them point nowhere by assigning 0 to them. You can make them
even point to places where they're in principle not supposed
to point by using casts. Also in this respect pointers to
arrays are in no way different from pointers to other kinds
of objects.
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.
I think you are thinking of an arrray as some kind of special C++ type
andf
converting that into an entitiy.
An array is just one of the types of objects that C++ knows.
An array is not a type of object. An array is a contiguous sequence of
objects.
There is no containing array type object
An array is not addressable in one whole chunk, it must be addressed in
sizeof(typeof array objects)
A pointer to array -type in C++ does not address an array , it addresses
an
object that is basically a pointer to the array under the hood.
Again, you are confusing arrays with pointers. Stop that
and things will become simple.
Im not confusing anything, that is how it works.
If you have an array of 500 ints how do you address such an array?
By using the address of the first byte in memory where the
array starts. Not even the slightest bit of a difference to
all other kind of objects in C++.
If the system has 4 byte integers then 500 integers = 2000 bytes.
You cannt have such a system that can address 2000 bytes. You can only
address individual elements of an array, it's technically impossible to
address the whole array.
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.
And if there wouldn't be the syntactic sugar that you can use
something like 'sp->x' to access the member 'x' of a structure
pointed to by 'sp' you'd be using the rather ugly syntax of
'(*sp).x' everywhere. If you compare that to an element access
via an array pointer the similarities becomes rather obvious:
I hate the term syntax sugar, ffs give me a break I am only concereced
with
asolute efficiency.
I do not even use the STD lib becuase its syntaxically extra code. But
processing speed is my my perogative, so I would use the libs if they
were
good for the job.
There's no difference in processing speed if you write '(*sp).x'
or 'sp->x' - the compiler will convert it into the exact same
machine instructions.
Lets be clear , what do you use an array for ?
Same as everyone else, I guess.
If it is nothing more than a string of chars then does it really matter?
If you are 3d programmer who transposes matixes on a daily basis then its
a
different subject.
I'm more interested in the maths that the C or C++ lang TBH , and as far
as
I can see there is too much focus about types that what the actuall
thing
represents.
Whether one is right or wrong I do not care, but I do care if somebody is
trying to make a statement of fact=that is actually incorrect.I am
mathematically minded and 1+1=2 , if you try to say 1+1=11. I will argue
with you becuase I do not accept nonsensical bullshit.
Well, I am also rather fond of mathematics and had to study
it for a few years. And one of my experiences is that it is
always advantageous when one understands something correctly
since it helps in avoiding mistakes and getting confused fur-
ther down the way. 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 :-)