pointer to array types

[Paul]

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.

 

[Peter Remmers]

Am 21.03.2011 18:52, schrieb Paul:

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

 

[Paul]

Am 21.03.2011 18:52, schrieb Paul:

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.

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?

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.

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.

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?

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

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.

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?

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

 

[Fred Zwarts]

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.

 

[Paul]

<sniP

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.

 

[Fred Zwarts]

<sniP
I'm not confused at all by your scenraio.



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




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.

 

[Fred Zwarts]

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

 

[Paul]

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*

 

[Paul]

<sniP
I'm not confused at all by your scenraio.



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




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.

 

[Paul]

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];

 

[Paul]

Correct but the reverse is not necessarily true; a fact that you have
repeatedly failed to grasp.

Wrong answer, the reverse is also true:

if it "points to a foo", by definition , it is a "pointer to a foo".
A "pointer to a foo" , by definition , "points to a foo".
You are an idiot.

 

[Fred Zwarts]

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];

If you think that the pointer to the old data-type is no longer valid,
it is you who is wrong.
*IntPointer = 3;

 

[Paul]

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];

As p is pointing to the initial element of an array one can say that it is
also "pointing to an array"

You are inconsistent and innacurate because below you state: "it is
certainly not a pointer to an array".
Above you say that "one can say it's pointing to an array", you don't seem
to know what it's pointing to.

however this is technically inaccurate as it is only, in reality as
defined by C++, pointing to an integer object which happens to be an array
element; it is certainly not a "pointer to an array".

The primary object it points to is the array-object. The pointer can be
incremented, decremented or offset to index the array using subscripting
syntax: It can point to any element you chose to index.
It can also point to none of the elements, as per C++ standard, one past the
end.
It certainly *is* a pointer to an array, you are not only innacurate but
also incorrect to say it's not.

 

[Paul]

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];

--If you think that the pointer to the old data-type is no longer valid,
--it is you who is wrong.
--*IntPointer = 3;

I didn't say the pointer was invalid. I said the pointer points-to the
union no matter what type the pointer was.
And you have just proved this is correct.

 

[Paul]

On 22/03/2011 15:19, Paul wrote:
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];

As p is pointing to the initial element of an array one can say that it
is
also "pointing to an array"

You are inconsistent and innacurate because below you state: "it is
certainly not a pointer to an array".
Above you say that "one can say it's pointing to an array", you don't seem
to know what it's pointing to.

He is quite consistent and accurate as he is able to contrast the
difference
between technical correctness and the looser, imprecise meaning associated
with
abstraction, something you clearly are unable to do.

Says who?.

Ahh, so you DO know how to cite the standard when it serves you, so lets
revisit
the statement you just made.

Paul says,"
In the context of int*p where does the standard say this exactly?

He is quite accurate and irrefutably correct.

Yes because *YOU* say so?

Your bullshit is not worth the electricity it consumes to view.

 

[Joshua Maurice]

You are inconsistent and innacurate because below you state: "it is
certainly not a pointer to an array".
Above you say that "one can say it's pointing to an array", you don't seem
to know what it's pointing to.

Again, I don't post this for the benefit of Paul, but for everyone
else. I have been not terribly satisfied with the answers to this
given thus far, so I post for the benefit of someone new to C++
reading this.

The statement "x is a pointer" is a statement about the type of the
variable and object named by the identifier "x".

The statement "x points to y" is a statement about the runtime value
of the pointer object x.

For example:
int* x = new int[10];
The following are all true:
- x is a pointer.
- x is a pointer to int.
- x is not a pointer to (int) array.
- x is not an (int) array.
- x points to an int.
- x points to an int array. This last statement is a little loose in
terminology, but most people would not normally consider it incorrect,
and it would be rather clear what was stated. Still, it's important to
understand the difference - under a particularly pedantic and
technical reading it does point to an int, and it does not point to an
int array, because that is the interpretation of the bit value under
its type of "pointer to int". This is despite that the "pointer to
first element" and "pointer to array" commonly have the same bit
value.

Related:
#include <iostream>
using namespace std;

template <typename T>
ostream& print_bit_representation(ostream& out, T const& x)
{
for (size_t i=0; i<sizeof(T); ++i)
out << (int)*(reinterpret_cast<unsigned char const*>(&x) + i) <<
" ";
return out;
}

int main()
{
typedef int (T)[10];

T x; //aka int x[10];
int* y = x;
T* z = &x; //aka int (*z)[10];

print_bit_representation(cout, y);
cout << endl;
print_bit_representation(cout, z);
cout << endl;
}
On my computer, the output is:
4 255 24 0
4 255 24 0
It doesn't have to be the same bit value, nor would I ever write code
to rely on such a thing, but as a matter of fact I expect that it
commonly is.

Finally, the property "x points to y" can be strictly defined as "the
pointer object x has the value of the address of the object y", but I
don't think most people use such a strict definition. Most people use
a looser definition. For example:
struct A {};
struct B : {};
B b;
A* a = &b;
I think that most people would not have a problem with saying "a
points to b", even though by the aforementioned strict definition of
"points to", a does not point to b. a doesn't hold the address of the
b object. It holds the address of the A sub-object. This difference is
incredibly important when explaining why reinterpret_cast-ing or C-
style casting willy nilly with virtual inheritance or multiple
inheritance doesn't do what you might naively expect it to.

 

[Joel C. Salomon]

Duty calls: <http://xkcd.com/386/>.

—Joel

 

[Paul]

Again, I don't post this for the benefit of Paul, but for everyone
else. I have been not terribly satisfied with the answers to this
given thus far, so I post for the benefit of someone new to C++
reading this.

The statement "x is a pointer" is a statement about the type of the
variable and object named by the identifier "x".

No that would be "x is a pointer type xxx".

The statement "x points to y" is a statement about the runtime value
of the pointer object x.

No it's a statement declaring what object x points to

For example:
int* x = new int[10];
The following are all true:

x is a location where a pointer sits.
The pointer is known by the name "x" and can point to any int (or contiguous
array of ints) anywhere.

- x is a pointer.
- x is a pointer to int.
- x is not a pointer to (int) array

No you allocated an array. It points to an array of ints.

- x is not an (int) array.
- x points to an int.
- x points to an int array. This last statement is a little loose in
terminology, but most people would not normally consider it incorrect,
and it would be rather clear what was stated.

x points to an array of ints.

Still, it's important to
understand the difference - under a particularly pedantic and
technical reading it does point to an int, and it does not point to an
int array,

I don't like your terminology re: points to an int array . The correct
terminology is: points to an array of ints.

because that is the interpretation of the bit value under
its type of "pointer to int". This is despite that the "pointer to
first element" and "pointer to array" commonly have the same bit
value.

x is a region of storage that contains a suitable pointer for the
implementation.
What bit value are you talking about?

Related:
#include <iostream>
using namespace std;

template <typename T>
ostream& print_bit_representation(ostream& out, T const& x)
{
for (size_t i=0; i<sizeof(T); ++i)
out << (int)*(reinterpret_cast<unsigned char const*>(&x) + i) <<
" ";
return out;
}

What is that stromash of confusion supposed to achieve?

int main()
{
typedef int (T)[10];

T x; //aka int x[10];
int* y = x;
T* z = &x; //aka int (*z)[10];

print_bit_representation(cout, y);
cout << endl;
print_bit_representation(cout, z);
cout << endl;
}
On my computer, the output is:
4 255 24 0
4 255 24 0
It doesn't have to be the same bit value, nor would I ever write code
to rely on such a thing, but as a matter of fact I expect that it
commonly is.

WTF are you talking about?

I'm sorry I have no desire to follow your code through multiple stages of
casts and coversions thoughout the iostreams classe and try to interpet what
might be going on at bit level on your implementation.


<snip>

 

[Joshua Maurice]

  struct A {};
  struct B : {};
  B b;
  A* a = &b;

Whoops, I meant:
struct B : A {};

It should be obvious anyway.

 

[ghartshaw]

Wrong answer, the reverse is also true:

if it "points to a foo", by definition , it is a "pointer to a foo".
A "pointer to a foo" , by definition , "points to a foo".



You are an idiot.

If A is true then B is true. B is true. Therefore, A is true.
This form of logical fallacy is called affirming the consequent.