Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > pointer to array types

Reply
Thread Tools

pointer to array types

 
 
Paul
Guest
Posts: n/a
 
      03-21-2011

"Fred Zwarts" <(E-Mail Removed)> wrote in message
news:im7p20$sht$(E-Mail Removed)...

<snip>
>>>>>>> It might happen to be the first (or second or tenth) element of an
>>>>>>> array,
>>>>>>> but that doesn't influence the pointer type. It's still a pointer to
>>>>>>> an
>>>>>>> int.
>>>>>>
>>>>>> You are clearly confused between:
>>>>>
>>>>> I'm not at all confused.
>>>>>
>>>>>> a) pointer to int
>>>>>> b) pointer to int-type
>>>>>
>>>>> Which is the same thing.
>>>>>
>>>> There you go , there is the source of your confusion.
>>>> It's not the same thing, if you have a pointer pointing to memory
>>>> location 0F0000, the entity at this location is what the pointer points
>>>> to.
>>>
>>>>Sorry, in C++ pointers don't point to types. Pointers point to objects.
>>>>So, a pointer to int-type is another language.

>>
>> No, pointers point to an entity, that entity is not necessarrilly an
>> object.
>> A pointer-to int-type means exactly the same thing as pointer-to entity
>> of int-type.
>>
>>>>The fact that the pointer contains the address of an object, does not
>>>>mean that it is a pointer to that object.

>> You mean thats what you've been thinking about?
>>>>Consider
>>>
>>>union AllTypes {
>>> int Integer;
>>> int IntArray[5];
>>> float Floating;
>>> float FloatArray[18];
>>>
>>> etc. etc.
>>>
>>>};
>>>
>>>AllTypes x;
>>>
>>>int * IntPointer = &x.Integer;
>>>
>>>Now IntPointer is a pointer to an int object.
>>>IntPointer is not a pointer to a float object.
>>>IntPointer is not a pointer to an float array.
>>>etc. etc.
>>>IntPointer is not a pointer to an int array.

>>
>> At the end of the day who cares what it's NOT a pointer to, what are you
>> trying to demonstrate?

>
> --Who cares? I thought you would care.
> --If not, finally, you don't care that IntPointer[2] can be used to access
> an
> --array element,
> --but that at the same time IntArray is not a pointer to an array.
>
>
> I don't know what you are trying to state , sorry.


--OK, let me see if I can say it even more clearly.

--IntPointer is a pointer to an object of type int.
--IntPointer now points to the int x.Integer.
--Because of the union, IntPointer[2] accesses an element of x.IntArray.

But does it? Or this this UB?

--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?

--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.

--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.

-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.

--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. The type of pointer
affects how the data will be interpreted when the pointer is dereferenced.
The type of pointer does not define what it points-to.

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'.


--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.
Whatever that address happens to be.
If it points-to the array, it points-to the array. How you manage to see
this as not pointing-to the array is very confusing and, though you might
choose to believe otherwise, definately not the correct terminology.


 
Reply With Quote
 
 
 
 
Peter Remmers
Guest
Posts: n/a
 
      03-21-2011
Am 21.03.2011 18:52, schrieb Paul:
>
> "Fred Zwarts"<(E-Mail Removed)> wrote in message
> news:im7p20$sht$(E-Mail Removed)...
>
> --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.
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".

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.

Actually, you use the type of the pointer to proclaim and document what
you're doing with your code.


> --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.

>
> --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.

> -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.

> --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.

> 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.

> The type of pointer does not define what it points-to.

The moment you use it to access the memory, it does.

> 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.

It is the combination of address and type that make a pointer "point to
a single int" or "point to an array of ints".

> --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.

> 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.

>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.

Peter
 
Reply With Quote
 
 
 
 
Paul
Guest
Posts: n/a
 
      03-21-2011

"Peter Remmers" <(E-Mail Removed)> wrote in message
news:4d87bbc7$0$7668$(E-Mail Removed)-online.net...
> Am 21.03.2011 18:52, schrieb Paul:
>>
>> "Fred Zwarts"<(E-Mail Removed)> wrote in message
>> news:im7p20$sht$(E-Mail Removed)...
>>
>> --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.

 
Reply With Quote
 
Fred Zwarts
Guest
Posts: n/a
 
      03-22-2011

"Paul" <(E-Mail Removed)> wrote in message
news:BfMhp.83509$(E-Mail Removed)2...
>
> "Fred Zwarts" <(E-Mail Removed)> wrote in message
> news:im7p20$sht$(E-Mail Removed)...
>
> <snip>
>>>>>>>> It might happen to be the first (or second or tenth) element of an
>>>>>>>> array,
>>>>>>>> but that doesn't influence the pointer type. It's still a pointer
>>>>>>>> to an
>>>>>>>> int.
>>>>>>>
>>>>>>> You are clearly confused between:
>>>>>>
>>>>>> I'm not at all confused.
>>>>>>
>>>>>>> a) pointer to int
>>>>>>> b) pointer to int-type
>>>>>>
>>>>>> Which is the same thing.
>>>>>>
>>>>> There you go , there is the source of your confusion.
>>>>> It's not the same thing, if you have a pointer pointing to memory
>>>>> location 0F0000, the entity at this location is what the pointer
>>>>> points to.
>>>>
>>>>>Sorry, in C++ pointers don't point to types. Pointers point to objects.
>>>>>So, a pointer to int-type is another language.
>>>
>>> No, pointers point to an entity, that entity is not necessarrilly an
>>> object.
>>> A pointer-to int-type means exactly the same thing as pointer-to entity
>>> of int-type.
>>>
>>>>>The fact that the pointer contains the address of an object, does not
>>>>>mean that it is a pointer to that object.
>>> You mean thats what you've been thinking about?
>>>>>Consider
>>>>
>>>>union AllTypes {
>>>> int Integer;
>>>> int IntArray[5];
>>>> float Floating;
>>>> float FloatArray[18];
>>>>
>>>> etc. etc.
>>>>
>>>>};
>>>>
>>>>AllTypes x;
>>>>
>>>>int * IntPointer = &x.Integer;
>>>>
>>>>Now IntPointer is a pointer to an int object.
>>>>IntPointer is not a pointer to a float object.
>>>>IntPointer is not a pointer to an float array.
>>>>etc. etc.
>>>>IntPointer is not a pointer to an int array.
>>>
>>> At the end of the day who cares what it's NOT a pointer to, what are you
>>> trying to demonstrate?

>>
>> --Who cares? I thought you would care.
>> --If not, finally, you don't care that IntPointer[2] can be used to
>> access an
>> --array element,
>> --but that at the same time IntArray is not a pointer to an array.
>>
>>
>> I don't know what you are trying to state , sorry.

>
> --OK, let me see if I can say it even more clearly.
>
> --IntPointer is a pointer to an object of type int.
> --IntPointer now points to the int x.Integer.
> --Because of the union, IntPointer[2] accesses an element of x.IntArray.
>
> But does it? Or this this UB?
>
> --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?
>
> --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.
>
> --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.


Your confusion leads you to wrong conclusions.
The pointer can still be used to assign an int value to x.Integer.
*IntPointer = 3;
So, it remains a valid pointer to int, even if the object at the memory
location is a float.

Even if the object currently present at the memory location is a float,
not an int, the pointer is still a pointer to an int and can be used as
such.
This shows that the identity of the object present at the memory
location is not what matters. It is the type of the pointer that matters.

Similarly, the fact that a pointer to int points to an int which happens to
be an element of an array,
does not make it a pointer to an array. The type determines that it is a
pointer to an int.


 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      03-22-2011

"Fred Zwarts" <(E-Mail Removed)> wrote in message
news:im9od4$4fe$(E-Mail Removed)...

<sniP
>> If you use the union as a float the memory location does not contain an
>> array.
>>
>> --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.

>
>Your confusion leads you to wrong conclusions.
>The pointer can still be used to assign an int value to x.Integer.
>*IntPointer = 3;
>So, it remains a valid pointer to int, even if the object at the memory
>location is a float.
>

I'm not confused at all by your scenraio.


>Even if the object currently present at the memory location is a float,
>not an int, the pointer is still a pointer to an int and can be used as
>such.


This shows that you are confused. by your own scenario. You just said if it
points to a float its still a pointer to int, what you probably meant was
that its type is still int*.


>This shows that the identity of the object present at the memory
>location is not what matters. It is the type of the pointer that matters.
>
>Similarly, the fact that a pointer to int points to an int which happens to
>be an element of an array,
>does not make it a pointer to an array. The type determines that it is a
>pointer to an int.



The pointer points to a union, not as you say, pointer to an int.
The pointer type does not determine what its pointing to. If it points to a
union, it points to a union, not an int.




 
Reply With Quote
 
Fred Zwarts
Guest
Posts: n/a
 
      03-22-2011

"Paul" <(E-Mail Removed)> wrote in message
news:062ip.148883$(E-Mail Removed)2...
>
> "Fred Zwarts" <(E-Mail Removed)> wrote in message
> news:im9od4$4fe$(E-Mail Removed)...
>
> <sniP
>>> If you use the union as a float the memory location does not contain an
>>> array.
>>>
>>> --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.

>>
>>Your confusion leads you to wrong conclusions.
>>The pointer can still be used to assign an int value to x.Integer.
>>*IntPointer = 3;
>>So, it remains a valid pointer to int, even if the object at the memory
>>location is a float.
>>

> I'm not confused at all by your scenraio.
>
>
>>Even if the object currently present at the memory location is a float,
>>not an int, the pointer is still a pointer to an int and can be used as
>>such.

>
> This shows that you are confused. by your own scenario. You just said if
> it points to a float its still a pointer to int, what you probably meant
> was that its type is still int*.
>
>
>>This shows that the identity of the object present at the memory
>>location is not what matters. It is the type of the pointer that matters.
>>
>>Similarly, the fact that a pointer to int points to an int which happens
>>to be an element of an array,
>>does not make it a pointer to an array. The type determines that it is a
>>pointer to an int.

>
>
> The pointer points to a union, not as you say, pointer to an int.


I hope I did not parse this sentence correctly,
But this is what I understand.
There is a pointer of type int*,
which can be used to store an int in memory
and to retrieve an int from memory.
But you say its is not a pointer to an int?
If so, I'm afraid there is no hope.
We speak incompatible languages.

 
Reply With Quote
 
Fred Zwarts
Guest
Posts: n/a
 
      03-22-2011

"Paul" <(E-Mail Removed)> wrote in message
news:062ip.148883$(E-Mail Removed)2...
>
> "Fred Zwarts" <(E-Mail Removed)> wrote in message
> news:im9od4$4fe$(E-Mail Removed)...
>
> <sniP
>>> If you use the union as a float the memory location does not contain an
>>> array.
>>>
>>> --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.

>>
>>Your confusion leads you to wrong conclusions.
>>The pointer can still be used to assign an int value to x.Integer.
>>*IntPointer = 3;
>>So, it remains a valid pointer to int, even if the object at the memory
>>location is a float.
>>

> I'm not confused at all by your scenraio.


That is right. Your wrong conclusion does not come from my scenario,
but from your ideas about pointers that are incompatible with the C++
language.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      03-22-2011

"Leigh Johnston" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ...
> On 22/03/2011 14:11, Paul wrote:
>>
>> "Fred Zwarts" <(E-Mail Removed)> wrote in message
>> news:im9od4$4fe$(E-Mail Removed)...
>>
>> <sniP
>>>> If you use the union as a float the memory location does not contain
>>>> an array.
>>>>
>>>> --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.
>>>
>>> Your confusion leads you to wrong conclusions.
>>> The pointer can still be used to assign an int value to x.Integer.
>>> *IntPointer = 3;
>>> So, it remains a valid pointer to int, even if the object at the
>>> memory location is a float.
>>>

>> I'm not confused at all by your scenraio.
>>
>>
>>> Even if the object currently present at the memory location is a float,
>>> not an int, the pointer is still a pointer to an int and can be used
>>> as such.

>>
>> This shows that you are confused. by your own scenario. You just said if
>> it points to a float its still a pointer to int, what you probably meant
>> was that its type is still int*.
>>
>>
>>> This shows that the identity of the object present at the memory
>>> location is not what matters. It is the type of the pointer that
>>> matters.
>>>
>>> Similarly, the fact that a pointer to int points to an int which
>>> happens to be an element of an array,
>>> does not make it a pointer to an array. The type determines that it is
>>> a pointer to an int.

>>
>>
>> The pointer points to a union, not as you say, pointer to an int.
>> The pointer type does not determine what its pointing to. If it points
>> to a union, it points to a union, not an int.
>>

>
> How many more times do I have to tell you that "points to a foo" IS
> DIFFERENT TO "pointer to a foo".
>
> Clueless. *shakes head*
>

A "pointer to a foo" , by definition , "points to a foo".

*is well beyond the head shaking stage*

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      03-22-2011

"Fred Zwarts" <(E-Mail Removed)> wrote in message
news:imadbr$j5i$(E-Mail Removed)...

"Paul" <(E-Mail Removed)> wrote in message
news:062ip.148883$(E-Mail Removed)2...
>
> "Fred Zwarts" <(E-Mail Removed)> wrote in message
> news:im9od4$4fe$(E-Mail Removed)...
>
> <sniP
>>> If you use the union as a float the memory location does not contain an
>>> array.
>>>
>>> --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.

>>
>>Your confusion leads you to wrong conclusions.
>>The pointer can still be used to assign an int value to x.Integer.
>>*IntPointer = 3;
>>So, it remains a valid pointer to int, even if the object at the memory
>>location is a float.
>>

> I'm not confused at all by your scenraio.
>
>
>>Even if the object currently present at the memory location is a float,
>>not an int, the pointer is still a pointer to an int and can be used as
>>such.

>
> This shows that you are confused. by your own scenario. You just said if
> it points to a float its still a pointer to int, what you probably meant
> was that its type is still int*.
>
>
>>This shows that the identity of the object present at the memory
>>location is not what matters. It is the type of the pointer that matters.
>>
>>Similarly, the fact that a pointer to int points to an int which happens
>>to be an element of an array,
>>does not make it a pointer to an array. The type determines that it is a
>>pointer to an int.

>
>
> The pointer points to a union, not as you say, pointer to an int.


--I hope I did not parse this sentence correctly,
--But this is what I understand.
--There is a pointer of type int*,
--which can be used to store an int in memory
--and to retrieve an int from memory.
--But you say its is not a pointer to an int?

Correct, when it points to memory which holds a float. The pointer no longer
points to an int , no matter what type it is.

--If so, I'm afraid there is no hope.
--We speak incompatible languages.

So it seems, goodbye.

 
Reply With Quote
 
Paul
Guest
Posts: n/a
 
      03-22-2011

"Fred Zwarts" <(E-Mail Removed)> wrote in message
news:imadk7$k08$(E-Mail Removed)...

>>> If you use the union as a float the memory location does not contain an
>>> array.
>>>
>>> --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.

>>
>>Your confusion leads you to wrong conclusions.
>>The pointer can still be used to assign an int value to x.Integer.
>>*IntPointer = 3;
>>So, it remains a valid pointer to int, even if the object at the memory
>>location is a float.
>>

> I'm not confused at all by your scenraio.


--That is right. Your wrong conclusion does not come from my scenario,
--but from your ideas about pointers that are incompatible with the C++
--language.

If you think p does not point to an array then I think you'll find that
it's you who is wrong.

int*p = new int[3];




 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointer to an array vs pointer to pointer subramanian100in@yahoo.com, India C Programming 5 09-23-2011 10:28 AM
Pointer to array of array of const pointer RSL C++ 14 02-19-2010 02:06 PM
Array of pointer and pointer of array erfan C Programming 6 01-28-2008 08:55 PM
Casting from pointer types to non-pointer types jois.de.vivre@gmail.com C++ 11 06-07-2007 09:17 AM
Array of pointer Vs Pointer to Array sangeetha C Programming 9 10-09-2004 07:01 PM



Advertisments