Lets put it another way

[Vidar Hasfjord]

My C++ compiler does not support this.

It is a very simple class, part of the TR1 additions to the C++
standard released in 2005, which most modern compilers now support.
You'll also find a version in the Boost C++ libraries (Boost.Array),
should you use a legacy compiler:

http://www.boost.org/doc/libs/1_46_1/doc/html/array.html

 

[Paul]

-- void f()
-- {
-- int x[3];
-- }
--That allocates a piece of memory on the stack. (At least for all
--common implementations which happen to use stack.) That region of
--memory, which contains 3 contiguous int sub-objects (barring padding),
--is a single object. That is the array object. The array object
--contains the 3 int sub-objects. The array object is not some object
--distinct from the 3 int objects. The array object and the 3 int
--objects occupy the same region of memory. The 3 int objects are sub-
--objects of the array object. It behaves very similar to:
-- struct x_t { operator int* (); private: int x0; int x1; int x2; }
-- x_t x;

You have not described a non modifiable object, you have described 3
integer
objects that are modifiable.
This object you have described can be modified bit by bit , there is no
way
this object can be said to be a non modifiable array type object.

The only non modifable object here is the object represented by the
identifier arr. This object holds a vlaue that is a memory address and
this
value is not stored with the array of three integers. That means this
object
is an object in its own right that takes up memory over and above the
memory
used for the 3 integer objects.

--Array objects are not modifiable. That was not intended to mean that
--the memory of the object cannot change. It was a shorthand for several
--facts about the type system, including expressions of array type may
--not appear on the left hand side of built-in assignment operators.

What is means is that the value of an array type object cannot change ,
that
value is the address of the initial element of the array.

--And you are wrong. You are wrong by definition, and your views lead to
--demonstrably wrong conclusions. One such demonstration is the program
--I have else-thread that shows that "int(*)[3]" points to a region of
--memory of 3 contiguous int objects. There is no hidden unmodifiable
--pointer that points to the first element. It is a figment of your
--imagination.

Your code was full of reinterpret casts from int(*)[3] to const char*.
What you are suggesting is similar to this:

int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;
}

p is a pointer type that points to a non modifiable object of array type.
p needs to be dereferenced twice to access 6 contiguous objects, if I cast p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then it
is no longer a pointer of type int(*)[6], it now a different pointer type.

 

[Paul]

My C++ compiler does not support this.

It is a very simple class, part of the TR1 additions to the C++
standard released in 2005, which most modern compilers now support.
You'll also find a version in the Boost C++ libraries (Boost.Array),
should you use a legacy compiler:

http://www.boost.org/doc/libs/1_46_1/doc/html/array.html

 

[Joshua Maurice]

What you are suggesting is similar to this:

int main(){
 int arr[6]={49,50,51};
 int (*p)[6] = &arr;
 char* c = (char*)p;
 std::cout<<*c;

}

p is a pointer type that points to a non modifiable object of array type.
p needs to be dereferenced twice to access 6 contiguous objects, if I cast p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then it
is no longer a pointer of type int(*)[6], it now a different pointer type..

Wait... the hidden pointer that you claim exists which points to the
first element of the array, the so called array type object, that has
the same address as the first int object? What? How does that work?
They share memory? How can a pointer value exist in the same memory as
a distinct int object?

Also, you are wrong. Array objects contain their element sub-objects.
The element sub-objects are modifiable, but the array object is not
modifiable insofaras expressions of array type may not appear on the
left hand side of a built-in assignment operator. The "int(*)[3]"
points into a region of memory which contains the array object and
which also contains the int sub-objects. The name of an array denotes
the region of memory which contains the array object and which also
contains the int sub-objects.

 

[Paul]

So you say that *p2 is not an object? I can accept that I don't know
what
the rules are which the reason for my OP.
But in argument to what you say, consider this:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
std::cout<< *p2<<std::endl;
std::cout<< typeid(*p2).name();
Is *p2 an object now?

--*p is an expression of object type. Its value is the result of a bogus
--cast, and most attempts to use that expression will run afoul of the
--strict aliasing rules.

What do you mean by bogus cast?

Does an object of array type exist ?

--An object of array type does exist yes.

What stage of the code creates the object of array type then?
Do you think new creates an non modifiable object of array type?

--You casted the result of a new expression to a "incompatible" pointer
--type. You took an expression of type "int*" and casted it to type
--"int(*)[3]".

Why do you think they are incomaptable , the pointer types both point to
the
same location.

--First. You're not guaranteed that a "int(*)[3]" has enough precision
--to store a int*. You may lose precision. It may be "rounded".

It doesn't strore an int* it stores a value. A pointer value is a memory
address.
The memory address for an int and an array of integers is the same.

--Incorrect. On some obscure C++ implementations, sizeof(void*) is
--greater than sizeof(int*). The reason is that the underlying machine
--is only 64 bit addressable, but they wanted CHAR_BITS to be 8, that is
--they wanted char* to address units of 8 bits. Thus, most C++ pointers
--in that implementation are hardware addresses that address 64 bit
--units, but char pointers (and thus void pointers) actually are a bit
--more. They stored the address of the 64 bit unit, and they stored an
--offset into that 64 bit unit, to allow the user to code C++ code with
--char pointers that addressed 8 bit units.

But a pointer to an array of T's is the same type as a pointer to a T. So a
pointer to an array of array of T's would be the same size.
This would only be a problem if you cast from pointer to T to pointer to U.



--Also, with high gcc optimization, you may actually see its strict
--aliasing optimizations break your code. It's allowed to assume that
-- int* x;
-- int (*y)[3];
--do not alias, and it in fact assumes that they do not alias, and it
--reorders reads and writes as part of optimization according. Do some
--research on strict aliasing. My favorite resource on this topic is:

--http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html

I never tried gcc.

--Second, any attempt to use a dereference of the "int(*)[3]" pointer.
--will be undefined behavior. You obtained it improperly, that is
--through a reinterpret_cast (or equivalent C-style cast), and there are
--no exceptions that would make this allowed, that would make this not
--undefined behavior. Thus that code will run afoul of the strict
--aliasing rules "C++03, 3.10 Lvalues and rvalues / 15" and have
--undefined behavior.

So any reinterpret cast in C++ results in UB?

--Pretty much, yeah. There's some important and notable exceptions (such
--as: casting to char or unsigned char*, or conversions between pointers
--of sufficient size and alignment, or conversions between pointers and
--integers of sufficient size, conversions between a pointer to POD-
--struct and a pointer to its first element), but let's just say for the
--moment that most uses reinterpret_cast produce UB.

Well I know my cast is pretty well defined on most normal desktop pc's and
for the sake of this discussion that is acceptable. I could add some checks
if it were production code but its not necessary for simple example code
snippets.

 

[Paul]

What you are suggesting is similar to this:

int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;

}

p is a pointer type that points to a non modifiable object of array type.
p needs to be dereferenced twice to access 6 contiguous objects, if I cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then
it
is no longer a pointer of type int(*)[6], it now a different pointer type.

--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?

Its not hidden, in the code above arr is an object of array type. My OP did
not contain such an object and this was what I was discussing. You cannot
even accept this obvious code where there is obviously an object of array
type present.
I thought we had got over that hurdle and you had come to accept that a non
modifiable object of array type exists.


--They share memory? How can a pointer value exist in the same memory as
--a distinct int object

What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is not
hidden, it's an object of array type.

 

[Joshua Maurice]

So you say that *p2 is not an object? I can accept that I don't know
what
the rules are which the reason for my OP.
But in argument to what you say, consider this:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
std::cout<< *p2<<std::endl;
std::cout<< typeid(*p2).name();
Is *p2 an object now?
--*p is an expression of object type. Its value is the result of a bogus
--cast, and most attempts to use that expression will run afoul of the
--strict aliasing rules.
What do you mean by bogus cast?
Does an object of array type exist ?

--An object of array type does exist yes.

What stage of the code creates the object of array type then?
Do you think new creates an non modifiable object of array type?

--You casted the result of a new expression to a "incompatible" pointer
--type. You took an expression of type "int*" and casted it to type
--"int(*)[3]".

Why do you think they are incomaptable , the pointer types both point to
the
same location.

--First. You're not guaranteed that a "int(*)[3]" has enough precision
--to store a int*. You may lose precision. It may be "rounded".

It doesn't strore an int* it stores a value. A pointer value is a memory
address.
The memory address for an int and an array of integers is the same.

--Incorrect. On some obscure C++ implementations, sizeof(void*) is
--greater than sizeof(int*). The reason is that the underlying machine
--is only 64 bit addressable, but they wanted CHAR_BITS to be 8, that is
--they wanted char* to address units of 8 bits. Thus, most C++ pointers
--in that implementation are hardware addresses that address 64 bit
--units, but char pointers (and thus void pointers) actually are a bit
--more. They stored the address of the 64 bit unit, and they stored an
--offset into that 64 bit unit, to allow the user to code C++ code with
--char pointers that addressed 8 bit units.

But a pointer to an array of T's is the same type as a pointer to a T. Soa
pointer to an array of array of T's would be the same size.
This would only be a problem if you cast from pointer to T to pointer to U.

You have no such guarantee by the standard.

In a similar thought as to the exotic implementation I mentioned which
has a 64 bit word, and its memory is addressable only by 64 bit units
(and no finer), it's possible and conforming to have:
CHAR_BITS == 8
sizeof(char*) == 16
sizeof(int*) == 8
sizeof(char(*)[3]) == 8
The implementation as a matter of internal undocumented implementation
details may choose to create arrays always starting at 64 word
boundaries, and as such it could have pointers to all arrays, char
arrays included, require only a hardware address without an offset
into the word, but a char pointer would require both a hardware
address and an offset into the word. There may even be compelling
reasons to do this. I can't dismiss such a possibility offhand.

--Second, any attempt to use a dereference of the "int(*)[3]" pointer.
--will be undefined behavior. You obtained it improperly, that is
--through a reinterpret_cast (or equivalent C-style cast), and there are
--no exceptions that would make this allowed, that would make this not
--undefined behavior. Thus that code will run afoul of the strict
--aliasing rules "C++03, 3.10 Lvalues and rvalues / 15" and have
--undefined behavior.

So any reinterpret cast in C++ results in UB?

--Pretty much, yeah. There's some important and notable exceptions (such
--as: casting to char or unsigned char*, or conversions between pointers
--of sufficient size and alignment, or conversions between pointers and
--integers of sufficient size, conversions between a pointer to POD-
--struct and a pointer to its first element), but let's just say for the
--moment that most uses reinterpret_cast produce UB.

Well I know my cast is pretty well defined on most normal desktop pc's and
for the sake of this discussion that is acceptable. I could add some checks
if it were production code but its not necessary for simple example code
snippets.

If by "most normal desktop PCs", you mean "has undefined behavior" and
"compiler writers won't guarantee anything", then sure. Have fun
playing with fire and writing buggy code.

Playing around with it, and what little I know of gcc, gcc won't break
your code, but only by luck. That's one possible outcome of UB. As far
as I can tell, gcc only does strict aliasing optimizations based on
the final lvalue used to the read or write, and only with fundamental
types. In the way that you're using this bad cast, and because the
implementation detail that the address of the array happens to be the
first element of the array, it happens to work out. It can break in
the future, and it can break on some more exotic architectures, and it
can break under a good debugging implementation.

 

[Joshua Maurice]

What you are suggesting is similar to this:

int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;

}

p is a pointer type that points to a non modifiable object of array type.
p needs to be dereferenced twice to access 6 contiguous objects, if I cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then
it
is no longer a pointer of type int(*)[6], it now a different pointer type.

--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?

Its not hidden, in the code above arr is an object of array type. My OP did
not contain such an object and this was what I was discussing. You cannot
even accept this obvious code where there is obviously an object of array
type present.
I thought we had got over that hurdle and you had come to accept that a non
modifiable object of  array type exists.

--They share memory? How can a pointer value exist in the same memory as
--a distinct int object

What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is not
hidden, it's an object of array type.

Nope. An array object is a region of memory which contains the array
elements. An array object does not contain a pointer to the first
array element. An array object does not occupy a separate region of
memory from the array elements. The array elements are sub-objects of
the array object.

 

[Ian Collins]

It isn't passed an object. It gives us the *static* type of the
expression
it is applied to. The exception is when the expression is polymorphic
class type.

So you say that *p2 is not an object? I can accept that I don't know what
the rules are which the reason for my OP.

But in argument to what you say, consider this:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
std::cout<< *p2<<std::endl;
std::cout<< typeid(*p2).name();


Is *p2 an object now?

In the context of typeid, no. It is an expression (which has a type).

This is not the question, It doesn't matter what typeid thinks of it.
DOes p2 point to an object of array type?

No, it points to the first of three ints returned by new. It's type is
int[3], but that's not what it is pointing to.

 

[Paul]

What you are suggesting is similar to this:

int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;

}

p is a pointer type that points to a non modifiable object of array
type.
p needs to be dereferenced twice to access 6 contiguous objects, if I
cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then
it
is no longer a pointer of type int(*)[6], it now a different pointer
type.

--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?

Its not hidden, in the code above arr is an object of array type. My OP
did
not contain such an object and this was what I was discussing. You cannot
even accept this obvious code where there is obviously an object of array
type present.
I thought we had got over that hurdle and you had come to accept that a
non
modifiable object of array type exists.

--They share memory? How can a pointer value exist in the same memory as
--a distinct int object

What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is not
hidden, it's an object of array type.

--Nope. An array object is a region of memory which contains the array
--elements. An array object does not contain a pointer to the first
--array element. An array object does not occupy a separate region of
--memory from the array elements. The array elements are sub-objects of
--the array object.

So what is the object that contains the address of the first element, is non
modifiable, is shown as an array type when passed to typeinfo and shows the
sizeof the array when passed to sizeof?
What is this object ?

It is an array type object, and if refuse to acknowledge the existence of
this object there is no point in dusccussing this any further with you.
..

 

[Paul]

On 05/26/11 10:09 AM, Paul wrote:

It isn't passed an object. It gives us the *static* type of the
expression
it is applied to. The exception is when the expression is polymorphic
class type.

So you say that *p2 is not an object? I can accept that I don't know
what
the rules are which the reason for my OP.

But in argument to what you say, consider this:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
std::cout<< *p2<<std::endl;
std::cout<< typeid(*p2).name();


Is *p2 an object now?

In the context of typeid, no. It is an expression (which has a type).

This is not the question, It doesn't matter what typeid thinks of it.
DOes p2 point to an object of array type?

No, it points to the first of three ints returned by new. It's type is
int[3], but that's not what it is pointing to.

--

So you think it points to a single int object and not an array of integer
objects?

I definately disagree with that. At the very least it must point to the
three integer objects returned from new.

 

[Paul]

So you say that *p2 is not an object? I can accept that I don't know
what
the rules are which the reason for my OP.
But in argument to what you say, consider this:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
std::cout<< *p2<<std::endl;
std::cout<< typeid(*p2).name();
Is *p2 an object now?
--*p is an expression of object type. Its value is the result of a
bogus
--cast, and most attempts to use that expression will run afoul of the
--strict aliasing rules.
What do you mean by bogus cast?
Does an object of array type exist ?

--An object of array type does exist yes.

What stage of the code creates the object of array type then?
Do you think new creates an non modifiable object of array type?

--You casted the result of a new expression to a "incompatible" pointer
--type. You took an expression of type "int*" and casted it to type
--"int(*)[3]".

Why do you think they are incomaptable , the pointer types both point to
the
same location.

--First. You're not guaranteed that a "int(*)[3]" has enough precision
--to store a int*. You may lose precision. It may be "rounded".

It doesn't strore an int* it stores a value. A pointer value is a memory
address.
The memory address for an int and an array of integers is the same.

--Incorrect. On some obscure C++ implementations, sizeof(void*) is
--greater than sizeof(int*). The reason is that the underlying machine
--is only 64 bit addressable, but they wanted CHAR_BITS to be 8, that is
--they wanted char* to address units of 8 bits. Thus, most C++ pointers
--in that implementation are hardware addresses that address 64 bit
--units, but char pointers (and thus void pointers) actually are a bit
--more. They stored the address of the 64 bit unit, and they stored an
--offset into that 64 bit unit, to allow the user to code C++ code with
--char pointers that addressed 8 bit units.

But a pointer to an array of T's is the same type as a pointer to a T. So
a
pointer to an array of array of T's would be the same size.
This would only be a problem if you cast from pointer to T to pointer to
U.

--You have no such guarantee by the standard.

I don't need a guarantee form the standard, thats just how things are.

int* and int(*)[n] are pointers of the same size. They both store the
address of an integer, and the size of this address does not change on any
one platform.


<snip>


<snip>

 

[Joshua Maurice]

What you are suggesting is similar to this:
int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;
}
p is a pointer type that points to a non modifiable object of array
type.
p needs to be dereferenced twice to access 6 contiguous objects, if I
cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But then
it
is no longer a pointer of type int(*)[6], it now a different pointer
type.

--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?

Its not hidden, in the code above arr is an object of array type. My OP
did
not contain such an object and this was what I was discussing. You cannot
even accept this obvious code where there is obviously an object of array
type present.
I thought we had got over that hurdle and you had come to accept that a
non
modifiable object of array type exists.

--They share memory? How can a pointer value exist in the same memory as
--a distinct int object

What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is not
hidden, it's an object of array type.

--Nope. An array object is a region of memory which contains the array
--elements. An array object does not contain a pointer to the first
--array element. An array object does not occupy a separate region of
--memory from the array elements. The array elements are sub-objects of
--the array object.

So what is the object that contains the address of the first element, is non
modifiable, is shown as an array type when passed to typeinfo and shows the
sizeof the array when passed to sizeof?
What is this object ?

void foo() { int x[3]; }
In the above function, there is no object which holds the address of
the first array element. There is an array object. The array object
has an identifier, "x". typeinfo when applied to "x" shows something
like "int[3]", and sizeof applied to "x" shows something like
"12" (for sizeof(int) == 4). The array object "x" is not modifiable.
The array elements, the int sub-objects, are modifiable.

It is an array type object,  and if refuse to acknowledge the existenceof
this object there is no point in dusccussing this any further with you.

Indeed.

 

[Paul]

What you are suggesting is similar to this:
int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;
}
p is a pointer type that points to a non modifiable object of array
type.
p needs to be dereferenced twice to access 6 contiguous objects, if I
cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But
then
it
is no longer a pointer of type int(*)[6], it now a different pointer
type.

--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?

Its not hidden, in the code above arr is an object of array type. My OP
did
not contain such an object and this was what I was discussing. You
cannot
even accept this obvious code where there is obviously an object of
array
type present.
I thought we had got over that hurdle and you had come to accept that a
non
modifiable object of array type exists.

--They share memory? How can a pointer value exist in the same memory as
--a distinct int object

What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is
not
hidden, it's an object of array type.

--Nope. An array object is a region of memory which contains the array
--elements. An array object does not contain a pointer to the first
--array element. An array object does not occupy a separate region of
--memory from the array elements. The array elements are sub-objects of
--the array object.

So what is the object that contains the address of the first element, is
non
modifiable, is shown as an array type when passed to typeinfo and shows
the
sizeof the array when passed to sizeof?
What is this object ?

-- void foo() { int x[3]; }
--In the above function, there is no object which holds the address of
--the first array element.
How do you know?
add the line:
std::cout<<x;
and there is an object which holds a memory address.


--There is an array object. The array object
--has an identifier, "x". typeinfo when applied to "x" shows something
--like "int[3]", and sizeof applied to "x" shows something like
--"12" (for sizeof(int) == 4). The array object "x" is not modifiable.
--The array elements, the int sub-objects, are modifiable.

No the array object is modifiable, the array object is the array of integer
objects, and if these integer objects are modified the array itself is also
modified.
The object "x" is of array type and is a non modifiable object that stores
the address of the array. This address is not stored within the same memory
as the array of integer objects. This address value will be stored in some
read only memory area.

It is an array type object, and if refuse to acknowledge the existence of
this object there is no point in dusccussing this any further with you.

--Indeed.

Well you are wrong because the C++ standard clearly acknoweldges the
existence of this array type object that is non modifiable.

The problem is that you are confused and cannot deduce by context when the
C++ standard is speaking about a non modifiable array type object, or a
completely modifiable array of T type objects.

 

[Paul]

On 05/25/11 12:58 AM, Paul wrote:

Ok in connection to my previous post, lets remove the null pointer
issue
and
consider this:
#include<iostream>
typedef int (*pparr)[3];
int main(){
pparr p1 = (pparr)new int[3];
pparr p2= p1;
delete[] p1;
std::cout<< *p2<<std::endl;
UB yet again.
std::cout<< typeid(*p2).name();
}
In the last 2 lines does an array type object exist, even though
there
is
no
array object?
No.
If not what is the object that stores the address and is
interpreted
as
an
array type by the typeid expression?
The typeid and sizeof operators do not evaluate their expression
(unless
in case of typeid the type is polymorphic). So no object is
required.
You do not seem to understand the question.
You do not appear to understand the answer.
I said ..if not what is the object that stores the address?
So what is this object? Do you know?
There isn't an object. The compiler knows the type of *p2. You may as
well have written
#include<iostream>
#include<typeinfo>
typedef int (*pparr)[3];
int main(){
pparr p2;
std::cout<< typeid(*p2).name()<< std::endl;
}
You are not addressing the what stores the memory address.

Because there isn't an address to store. The typeid operator (like
sizeof) works with types, not values. In a simple case such as this the
operand is not evaluated. Until you understand this you will be stuck in
limbo.

I could have simplified my simplification further by writing

std::cout << typeid(int[3]).name() << std::endl;

See? No memory address just a type.

There is an address stored.

Look at the code :

int main(){
int (*pp)[3] = (int (*)[3])new int[3];
std::cout<<*pp;}

If this does not output an address what the hell is it?

There isn't an address. Where's the address in typeid(int).name()? Or
sizeof(int)?

The address is shown in my code above.
Have you lost your brain today?

--**** yeah! Your posts ROCK!!

Hey dude <thumbsup>

 

[Joshua Maurice]

What you are suggesting is similar to this:
int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;
}
p is a pointer type that points to a non modifiable object of array
type.
p needs to be dereferenced twice to access 6 contiguous objects, ifI
cast
p
to a different type then yes I can skip over the array type object it
originally pointed to , becase the address values are the same. But
then
it
is no longer a pointer of type int(*)[6], it now a different pointer
type.
--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that has
--the same address as the first int object? What? How does that work?
Its not hidden, in the code above arr is an object of array type. My OP
did
not contain such an object and this was what I was discussing. You
cannot
even accept this obvious code where there is obviously an object of
array
type present.
I thought we had got over that hurdle and you had come to accept thata
non
modifiable object of array type exists.
--They share memory? How can a pointer value exist in the same memoryas
--a distinct int object
What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is
not
hidden, it's an object of array type.

--Nope. An array object is a region of memory which contains the array
--elements. An array object does not contain a pointer to the first
--array element. An array object does not occupy a separate region of
--memory from the array elements. The array elements are sub-objects of
--the array object.

So what is the object that contains the address of the first element, is
non
modifiable, is shown as an array type when passed to typeinfo and shows
the
sizeof the array when passed to sizeof?
What is this object ?

--    void foo() { int x[3]; }
--In the above function, there is no object which holds the address of
--the first array element.
How do you know?
add the line:
 std::cout<<x;
and there is an object which holds a memory address.

--There is an array object. The array object
--has an identifier, "x". typeinfo when applied to "x" shows something
--like "int[3]", and sizeof applied to "x" shows something like
--"12" (for sizeof(int) == 4). The array object "x" is not modifiable..
--The array elements, the int sub-objects, are modifiable.

No the array object is modifiable, the array object is the array of integer
objects, and if these integer objects are modified the array itself is also
modified.
The object "x" is of array type and is a non modifiable object that stores
the address of the array. This address is not stored within the same memory
as the array of integer objects. This address value will be stored in some
read only memory area.

It is an array type object, and if refuse to acknowledge the existence of
this object there is no point in dusccussing this any further with you.

--Indeed.

Well you are wrong because the C++ standard clearly acknoweldges the
existence of this array type object that is non modifiable.

The problem is that you are confused and cannot deduce by context when the
C++ standard is speaking about a non modifiable array type object, or a
completely modifiable array of T type objects.

You know. I'm actually happy now. It took months, but I finally
understand exactly where you're coming from. I usually have this knack
to understand silly people when they're making silly arguments, but I
was failing with you for the longest time. I have suspected that you
aren't actually a troll, but just an obstinate and uncouth person, and
that's why it really irritated me that I couldn't understand what you
were saying. I wouldn't mind if I thought you were a troll, but I
don't think you are, and that's why it really bothered me that I
didn't understand you. So, thanks for sticking in there. Because of
that, now I can safely disregard everything you say, and refute to
your future threads with one liners, in order to maintain the
relatively high standard of accuracy that this forum has.

Thank you, and good day.

 

[Paul]

int main(){
int arr[6]={49,50,51};
int (*p)[6] = &arr;
char* c = (char*)p;
std::cout<<*c;
}
p is a pointer type that points to a non modifiable object of array
type.
p needs to be dereferenced twice to access 6 contiguous objects, if
I
cast
p
to a different type then yes I can skip over the array type object
it
originally pointed to , becase the address values are the same. But
then
it
is no longer a pointer of type int(*)[6], it now a different pointer
type.
--Wait... the hidden pointer that you claim exists which points to the
--first element of the array, the so called array type object, that
has
--the same address as the first int object? What? How does that work?
Its not hidden, in the code above arr is an object of array type. My
OP
did
not contain such an object and this was what I was discussing. You
cannot
even accept this obvious code where there is obviously an object of
array
type present.
I thought we had got over that hurdle and you had come to accept that
a
non
modifiable object of array type exists.
--They share memory? How can a pointer value exist in the same memory
as
--a distinct int object
What are you talking about here?
The valueof arr is a pointer value. It doesn't share memory and it is
not
hidden, it's an object of array type.

--Nope. An array object is a region of memory which contains the array
--elements. An array object does not contain a pointer to the first
--array element. An array object does not occupy a separate region of
--memory from the array elements. The array elements are sub-objects of
--the array object.

So what is the object that contains the address of the first element, is
non
modifiable, is shown as an array type when passed to typeinfo and shows
the
sizeof the array when passed to sizeof?
What is this object ?

-- void foo() { int x[3]; }
--In the above function, there is no object which holds the address of
--the first array element.
How do you know?
add the line:
std::cout<<x;
and there is an object which holds a memory address.

--There is an array object. The array object
--has an identifier, "x". typeinfo when applied to "x" shows something
--like "int[3]", and sizeof applied to "x" shows something like
--"12" (for sizeof(int) == 4). The array object "x" is not modifiable.
--The array elements, the int sub-objects, are modifiable.

No the array object is modifiable, the array object is the array of
integer
objects, and if these integer objects are modified the array itself is
also
modified.
The object "x" is of array type and is a non modifiable object that stores
the address of the array. This address is not stored within the same
memory
as the array of integer objects. This address value will be stored in some
read only memory area.

It is an array type object, and if refuse to acknowledge the existence
of
this object there is no point in dusccussing this any further with you.

--Indeed.

Well you are wrong because the C++ standard clearly acknoweldges the
existence of this array type object that is non modifiable.

The problem is that you are confused and cannot deduce by context when the
C++ standard is speaking about a non modifiable array type object, or a
completely modifiable array of T type objects.

--You know. I'm actually happy now. It took months, but I finally
--understand exactly where you're coming from. I usually have this knack
--to understand silly people when they're making silly arguments, but I
--was failing with you for the longest time. I have suspected that you
--aren't actually a troll, but just an obstinate and uncouth person, and
--that's why it really irritated me that I couldn't understand what you
--were saying. I wouldn't mind if I thought you were a troll, but I
--don't think you are, and that's why it really bothered me that I
--didn't understand you. So, thanks for sticking in there. Because of
--that, now I can safely disregard everything you say, and refute to
--your future threads with one liners, in order to maintain the
--relatively high standard of accuracy that this forum has.

I suppose your idea of a high standard of accuracy means that a non
modifiable object is actually modifiable so you are welcome to your "high
level of accuracy".
It certainly isn't what I consider highly accurate.