Re: pointer to array types
"Peter Remmers" <p.remmers@expires-2011-03-31.arcornews.de> wrote in message
news:4d87bbc7$0$7668$9b4e6d93@newsspool1.arcor-online.net...
Am 21.03.2011 18:52, schrieb Paul:
"Fred Zwarts"<F.Zwarts@KVI.nl> wrote in message
news:im7p20$sht$1@news.albasani.net...
--I said that IntPointer is not a pointer to the array x.IntArray.
int* p = x.IntArray is a pointer to the array though.
--You said: Who cares?
--But earlier you said that if a pointer points to a memory location
--that contains an array, it must be a pointer to an array.
Yes this is true. How can it not be a pointer to an array if it points to
an
array?
It is an issue of "knowledge". You as the programmer who assigned the
address of the array to the pointer "knows" that at the memory location
you made it point to there is an array, because you created it there a few
lines of code before, or wherever.
Exactly.
The other "knowledge", however, is that which is encoded in the type of
the pointer variable. The type says "this pointer points to a single int".
That is not knowledge , that's guessing.
The type of an array is the same as a pointer to a single element as I can
prove:
template<typename T, typename T1>
struct is_same_type{
enum {value = 0};
};
template<typename T>
struct is_same_type<T,T>{
enum {value = 1};
};
template<typename T, typename U>
void f(T arg1, U arg2){std::cout <<"is_same_type:
"<<is_same_type<T,U>::value<<"\nvalue of arg1:\t" << arg1 << "\nvalue of
arg2:\t"<<*arg2;}
int main(){
char str[]= "hello";
char c = 'x';
char* p= &c;
f(str, p);
}
You keep trying to use your divine knowledge of what is really at the
respective memory location, while everyone tries to tell you that your
knowledge is not what is written down in the program code, and is not
something the compiler can know, nor a function that receives an "int*",
or a colleague that works on the other side of some interface.
If you create a function that takes a pointer to an array as a parameter,
you have to tell users that it expects an array.
void foo( p_arr*, int size);
If you were using this function the function should be documented to tell
you it takes an array, if you are creator you need to inform users.
Actually, you use the type of the pointer to proclaim and document what
you're doing with your code.
No never heard of this before, C++ has polymorphic types.
--So, I got the impression that you would care about this.
--Because of the union
--IntPointer also points to a memory location of a float
--and to a memory location of a float array, etc. etc.
If you use the union as a float the memory location does not contain an
array.
Yes, a memory location effectively contains the data that you interpret it
to be by using it as such. "Interpreting as some type" is done by the C++
type system. If you use an "int*", then you use the memory location it
points to exactly as if it were a single int. If you use pointer
arithmetics to access neighbouring integers, then you do that with your
divine knowledge -- or possibly just the unjustified assumption -- that
the single element the pointer points to actually does have valid int
neighbours.
So if I have an Animal pointer it can only point to a single Animal type?
--According to your reasoning,
--IntPointer would be also a pointer to a float,
--and to a float array, etc. etc.
No, when the union chnages to represent a new data-type the pointer to
the
old data-type is no longer valid IMO.
A union does not "change" by itself. A union is basically just an
elaborate type casting tool. You as the programmer decide in which way you
want to interpret the data it represents, by using the corresponding
member of the union.
Never used them much myself.
-After the assignment
- x.Floating=3.14;
-the memory location IntPointer points to, contains a float object.
-Still, IntPointer is not a pointer to a float
-and cannot be used like that without a cast.
As I said above the memory pointed-to would then no longer contain an int
or
an array of int. As you say to use the value of this pointer would
require a
cast.
What a memory location contains is purely a matter of interpretation. If
you interpret it the wrong way, then it may actually be UB. There's
objects with lifetimes that really occupy a memory location for some
well-defined duration. If you mis-interpret or wrongly overwrite the
object's data during its lifetime, then the compiler cannot prevent you
from doing that if you use a pointer with a wrong type or if you shut up
the compiler by casting the type. In the end it's all a matter of the
type.
Since you know so much about types , why don't you realise that that an
array is just a series of entities in contiguous memory all of the same
type? It's nothing more than that nor no less.
--So, the fact that the value of a pointer is an address
--of a memory location that happens to contain an object of some type,
--does not mean that the pointer is a pointer to such an object.
OFC it does.
void* p =&x; // points to x and all its members.
A void* points to some memory location without giving any clue as to what
kind of data that may be. You can't say it points to "this" or "that". If
you do, you are using your divine knowledge of the program code elsewhere
in the source. And if this "elsewhere" is just "the previous line", it is
still insider knowledge.
void* union_of_int_types =&x;
How about this ? does this give any clues as to what may be there?
The type of pointer
affects how the data will be interpreted when the pointer is
dereferenced.
Yes. That's what it's all about and that's all there is to it. You just
cannot accept this fact.
How can I not accept it , it was me who said it first?
The type of pointer does not define what it points-to.
The moment you use it to access the memory, it does.
I disagree , I think it's ridiculous to suggest that a type defines data.
The deifnition of data is down to humans.
I can create a buffer of data made up from different types, and convert it
into another types and define it how I like, the types don't define the
data.
Your example does not represent an array because arrays and their
elements
are of the same type..
With arrays:
int arr[5]; //array of type int.
int x; // variable of type int.
int* p; // can point to both 'an array of int' and 'a single int'.
To use your pile-of-bananas example: You said that if I use my finger to
point to a banana in the pile, that it is unclear whether I mean to point
to a single banana or to the whole bunch.
Well, imagine I have two fingers, and one is labeled "Single banana", and
the other is labeled "Banana pile", then it becomes clear what I mean to
point to, simply by using the appropriate finger. I could also just say
loud what I mean while I'm pointing with the finger.
Ok then given your scenrio , you must agree that with:
int* p1 = new int[10];
int* p2 = p1[0];
p1 points to an array of int's , p2 points to a single int.
If you agree with this then case closed. I am arguing with the people who
are saying p1 is not a pointer to an array.
>
It is the combination of address and type that make a pointer "point to a
single int" or "point to an array of ints".
Yes but the pointer is the same type ( for a 1dim array). For a 2dim array
you have a 2nd level of indirection , type would be int(*)[Size].
--Saying that an int* is a pointer to a float is not the intention of the
C++
--language,
--even if the address contained in it happens to be a location of a
float.
Well I'm not saying that at all , it's only you that has suggested that.
--So, may I conclude that an int* pointer that happens to contain the
address
--of an int array is not a pointer to an array according to the
terminology
of
--C++?
--Or do you still say: Who cares?
An int* that contains the address of an array, points to the array.
An int* that contains the address of an array, points to something that
is treated as an int then you use it to access that memory.
No you use it to access the array *first*, then it's dereferenced to produce
something that is treated like an int.
Whatever that address happens to be.
If it points-to the array, it points-to the array.
But you're the only one who "knows" that because you "know" that you put
an array there and assigned the address to the pointer.
Someone's gotta know how the pointer was initialised and allocated to. How
the hell do you keep track of who deletes it?
How you manage to see
this as not pointing-to the array is very confusing and, though you might
choose to believe otherwise,
You see it this way, I see it that way. We're back to the POV thing again.
I agree that you could say it points to the array because you have just
put an array there, but it is...
definately not the correct terminology.
if you want to be precise and be understood by others.
If it contains the address of the array, by definition , it points to the
array. It cannot possible not point to the array.