Lets put it another way

[Paul]

--Doesn't matter. It's UB. Attempting to read the pointer, not the
--deallocated memory, is UB. At least it is according to the C spec, and
--I expect that the C++ standard will follow suit if it hasn't already

This pointer obviously points to something that has a value that is
displayed on the screen as a memory address. It certainly doesn't point to
the integer objects that were allocated by new, so what does it point to?
How can you say it is UB if you do not first establish what it is pointing
to?

--Take the following program:
-- #include <stdlib.h>
-- #include <stdio.h>
-- int main()
-- { char* a = (char*)malloc(1);
-- char* b = a;
-- free(a);
-- printf("%p\n", b);
-- }
--This program has UB in C, and as I said will likely have UB in C++, or
--it already is UB in C++. See the defect report for more details:

--http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

This is not the same as what I did.

--And I still don't know what you mean by array type object vs array
--object. Until you explain that technical distinction to me, you're
--literally just spouting effective nonsense, as you just invented those
--terms and no one else knows what you're saying.

Well consider the following:

int arr[3]={0};
std::cout<< arr;

The above does not output an array object, it outputs a memory address.
To output the array object you need to loop and dereference:

for (int i=0; i<3; ++i){
std::cout<< arr << std::endl;

}

The array type object is a region of memory that contains a value that is
some memory address.
The array object is a region of memory than contains three integer
objects,
each with the value 0.

--I suggest you take a course in compilers, or read a book, like one of
--the Dragon Books, Red or Green. You have gross misunderstandings of
--both the C++ object model, and how compilers actually generate code.
--There is no such thing as an "array-type object", as you've defined
--it. In these examples, there are only array objects and pointer
--objects - including pointers to arrays and pointers to individual
--elements, not "array-type objects".

If there is no such thing as an array type object then what is the object
that is implicitly converted to a pointer, and stores a memory address?


--Consider:
-- void foo()
-- { int x[3];
-- int* y = x;
-- cout << y;
-- }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".


std::cout<< x;
//outputs a memory address.
std::cout<< typeid(x).name();
//outputs that x is an array type object.

"x" is an object that stores a memory address.
"x" is an array type object.

When the array to pointer conversion takes place what is converted to a
pointer?
It is not one of the three integer objects that is converted to a pointer,
it is the array type object.


--"y" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--a (pointer) object of type "int*". It holds the address of the first
--element of the auto (stack) array x.

y is a pointer.

This function "uses" the following objects:
- the array object x, and its 3 unnamed int sub-objects,
- the pointer object y,
- the object cout.
-There is no "array-type object".

Thats your opinion but you do not acknoweldge the object that stores the
address of the array, the object that is converted to a pointer on assignemt
to y.


<snip>

 

[Paul]

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

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?

The value returned by new.

Which is an address value.

The address in your code id the value return by new. No amount of casting
will change that.

The value returned from new is a pointer value that is an address.

Why do you think it is not an address?

 

[Joshua Maurice]

--Take the following program:
--  #include <stdlib.h>
--  #include <stdio.h>
--  int main()
-- { char* a = (char*)malloc(1);
--    char* b = a;
--    free(a);
--    printf("%p\n", b);
--  }
--This program has UB in C, and as I said will likely have UB in C++, or
--it already is UB in C++. See the defect report for more details:

--http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

This is not the same as what I did.

Yes it is.

--And I still don't know what you mean by array type object vs array
--object. Until you explain that technical distinction to me, you're
--literally just spouting effective nonsense, as you just invented those
--terms and no one else knows what you're saying.

Well consider the following:

int arr[3]={0};
std::cout<< arr;

The above does not output an array object, it outputs a memory address.
To output the array object you need to loop and dereference:

for (int i=0; i<3; ++i){
std::cout<< arr << std::endl;

}

The array type object is a region of memory that contains a value that is
some memory address.
The array object is a region of memory than contains three integer
objects,
each with the value 0.

--I suggest you take a course in compilers, or read a book, like one of
--the Dragon Books, Red or Green. You have gross misunderstandings of
--both the C++ object model, and how compilers actually generate code.
--There is no such thing as an "array-type object", as you've defined
--it. In these examples, there are only array objects and pointer
--objects - including pointers to arrays and pointers to individual
--elements, not "array-type objects".

If there is no such thing as an array type object then what is the object
that is implicitly converted to a pointer, and stores a memory address?

--Consider:
--  void foo()
--  { int x[3];
--    int* y = x;
--    cout << y;
--  }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".

std::cout<< x;
//outputs a memory address.
std::cout<< typeid(x).name();
//outputs that x is an array type object.

"x" is an object that stores a memory address.
"x" is an array type object.

When the array to pointer conversion takes place what is converted to a
pointer?
It is not one of the three integer objects that is converted to a pointer,
it is the array type object.

--"y" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--a (pointer) object of type "int*". It holds the address of the first
--element of the auto (stack) array x.

y is a pointer.

This function "uses" the following objects:
- the array object x, and its 3 unnamed int sub-objects,
- the pointer object y,
- the object cout.
-There is no "array-type object".

Thats your opinion but you do not acknoweldge the object that stores the
address of the array, the object that is converted to a pointer on assignemt
to y.

<snip>

That's nice. You're welcome to join the adult discussion when you
decide to adopt the community's terms instead of inventing your own.
Good day troll or obstinate person.

 

[Paul]

--Doesn't matter. It's UB. Attempting to read the pointer, not the
--deallocated memory, is UB. At least it is according to the C spec, and
--I expect that the C++ standard will follow suit if it hasn't already

This pointer obviously points to something that has a value that is
displayed on the screen as a memory address. It certainly doesn't point to
the integer objects that were allocated by new, so what does it point to?
How can you say it is UB if you do not first establish what it is pointing
to?

Take the following program:
#include <stdlib.h>
#include <stdio.h>
int main()
{ char* a = (char*)malloc(1);
char* b = a;
free(a);
printf("%p\n", b);
}
This program has UB in C, and as I said will likely have UB in C++, or
it already is UB in C++. See the defect report for more details:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

--And I still don't know what you mean by array type object vs array
--object. Until you explain that technical distinction to me, you're
--literally just spouting effective nonsense, as you just invented those
--terms and no one else knows what you're saying.

Well consider the following:

int arr[3]={0};
std::cout<< arr;

The above does not output an array object, it outputs a memory address.
To output the array object you need to loop and dereference:

for (int i=0; i<3; ++i){
std::cout<< arr << std::endl;

}

The array type object is a region of memory that contains a value that is
some memory address.
The array object is a region of memory than contains three integer
objects,
each with the value 0.

--I suggest you take a course in compilers, or read a book, like one of
--the Dragon Books, Red or Green. You have gross misunderstandings of
--both the C++ object model, and how compilers actually generate code.
--There is no such thing as an "array-type object", as you've defined
--it. In these examples, there are only array objects and pointer
--objects - including pointers to arrays and pointers to individual
--elements, not "array-type objects".

--Consider:
-- void foo()
-- { int x[3];
-- int* y = x;
-- cout << y;
-- }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".

The standard states that the identifier x is an array type. But you have
said it names an object which has an array type:
"..the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T", then the type of the identifier of D is an
array type"


Also the C++ standard states the following:
"5 [ Note: conversions affecting expressions of array type are described in
4.2. Objects of array types cannot be modified, see 3.10. -end note ]"


So what is this object of array type that cannot be modified?
Both quotes taken form section 8.3.4 Arrays, and easy to find.

 

[Paul]

--I suggest you take a course in compilers, or read a book, like one of
--the Dragon Books, Red or Green. You have gross misunderstandings of
--both the C++ object model, and how compilers actually generate code.
--There is no such thing as an "array-type object", as you've defined
--it. In these examples, there are only array objects and pointer
--objects - including pointers to arrays and pointers to individual
--elements, not "array-type objects".

If there is no such thing as an array type object then what is the object
that is implicitly converted to a pointer, and stores a memory address?

--Consider:
-- void foo()
-- { int x[3];
-- int* y = x;
-- cout << y;
-- }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".

std::cout<< x;
//outputs a memory address.
std::cout<< typeid(x).name();
//outputs that x is an array type object.

"x" is an object that stores a memory address.
"x" is an array type object.

When the array to pointer conversion takes place what is converted to a
pointer?
It is not one of the three integer objects that is converted to a pointer,
it is the array type object.

--"y" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--a (pointer) object of type "int*". It holds the address of the first
--element of the auto (stack) array x.

y is a pointer.

This function "uses" the following objects:
- the array object x, and its 3 unnamed int sub-objects,
- the pointer object y,
- the object cout.
-There is no "array-type object".

Thats your opinion but you do not acknoweldge the object that stores the
address of the array, the object that is converted to a pointer on
assignemt
to y.

<snip>

--That's nice. You're welcome to join the adult discussion when you
--decide to adopt the community's terms instead of inventing your own.
--Good day troll or obstinate person.


Is this your way of running away from the argument?

 

[Joel C. Salomon]

If there is no such thing as an array type object then what is the object
that is implicitly converted to a pointer, and stores a memory address?

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

("...The name of the song is called 'Haddocks' Eyes'!")

--Joel

 

[Joshua Maurice]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

No. There is an array object, and it is implicitly converted to a
pointer to the first element. Consider:

int x[3];
int (*y)[3] = x;
int* z = *y;

y is not the identifier of the array object. y is a pointer which
points to the array object. Derefencing y gives an expression of array
type, specifically "int[3]". Then a standard conversion sequence is
applied using the array-to-pointer conversion in the assignment to z.

 

[Joshua Maurice]

--Consider:
--  void foo()
--  { int x[3];
--    int* y = x;
--    cout << y;
--  }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".

The standard states that the identifier x is an array type. But you have
said it names an object which has an array type:
"..the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T", then the type of the identifier of D isan
array type"

Semantic quibble. The same meaning applies. The standard and most
people often conflate identifiers and what they identify. Usually
there is no ambiguity of meaning. There is no ambiguity of meaning
here either.

Also the C++ standard states the following:
"5 [ Note: conversions affecting expressions of array type are described in
4.2. Objects of array types cannot be modified, see 3.10. -end note ]"

So what is this object of array type that cannot be modified?
Both quotes taken form section 8.3.4 Arrays, and easy to find.

Array objects cannot be (directly) modified, but their sub-objects can
be modified.

int main()
{
int x[3] = {};
int y[3] = {};
x = y; //ill-formed
x[0] = y[0]; //valid
}

 

[Joshua Maurice]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

No. There is an array object, and it is implicitly converted to a
pointer to the first element. Consider:

  int x[3];
  int (*y)[3] = x;
  int* z = *y;

y is not the identifier of the array object. y is a pointer which
points to the array object. Derefencing y gives an expression of array
type, specifically "int[3]". Then a standard conversion sequence is
applied using the array-to-pointer conversion in the assignment to z.

Meh. Crap. That's what I get for posting code samples without running
it through a compiler. Here:
int x[3];
int (*y)[3] = &x;
int* z = *y;

 

[Paul]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

--No. There is an array object, and it is implicitly converted to a
--pointer to the first element. Consider:

-- int x[3];
-- int (*y)[3] = x;
-- int* z = *y;

I think you missed an &, line 2 should be:
int (*y)[3] = &x;



--y is not the identifier of the array object. y is a pointer which
--points to the array object. Derefencing y gives an expression of array
--type, specifically "int[3]". Then a standard conversion sequence is
--applied using the array-to-pointer conversion in the assignment to z.


Anyway so this array object is described in the standard as a non modifiable
object of array type. SO with :
int arr[5];

arr is an object of array type. Do you agree with this?
and when we do this:
int (*pparr)[5] =&arr;

pparr is a pointer to an object of array type. Do you agree with this?


The array type object , is an object that could be described as a non
modifiable pointer to the array of ints, with added typeinfo to support C++
references, sizeof and typeid.
Do you agree with this? If not what do you think is wrong about it?

 

[Joel C. Salomon]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

No. There is an array object, and it is implicitly converted to a
pointer to the first element. Consider:

  int x[3];
  int (*y)[3] = x;
  int* z = *y;

y is not the identifier of the array object. y is a pointer which
points to the array object. Derefencing y gives an expression of array
type, specifically "int[3]". Then a standard conversion sequence is
applied using the array-to-pointer conversion in the assignment to z.

I didn't think that would work until I tried it (including the "... =
&x;" fix you posted); I stand corrected.

Thank you.

--Joel

 

[Joshua Maurice]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

--No. There is an array object, and it is implicitly converted to a
--pointer to the first element. Consider:

--  int x[3];
--  int (*y)[3] = x;
--  int* z = *y;

I think you missed an &, line 2 should be:
int (*y)[3] = &x;

--y is not the identifier of the array object. y is a pointer which
--points to the array object. Derefencing y gives an expression of array
--type, specifically "int[3]". Then a standard conversion sequence is
--applied using the array-to-pointer conversion in the assignment to z.

Anyway so this array object is described in the standard as a non modifiable
object of array type. SO with :
int arr[5];

arr is an object of array type. Do you agree with this?
Yes.

and when we do this:
int (*pparr)[5] =&arr;

pparr is a pointer to an object of array type. Do you agree with this?
Yes.

The array type object

I don't know what that is. Do you mean object of array type?

is an object that could be described as a non
modifiable pointer to the array of ints, with added typeinfo to support C++
references, sizeof and typeid.
Do you agree with this? If not what do you think is wrong about it?

No it could not be described like that. As has been demonstrated
before, sizeof(arr) != sizeof(&arr[0]). What makes me think you're
wrong? A careful reading of the standard, my education, and how all
compilers are implemented.

 

[Paul]

--Consider:
-- void foo()
-- { int x[3];
-- int* y = x;
-- cout << y;
-- }

--"x" is a piece of text. It is a preprocessor token. It is an
--identifier for an auto (stack) variable. It names an object. It names
--an (array) object of type "int [3]". That array object has three sub-
--objects of type "int".

The standard states that the identifier x is an array type. But you have
said it names an object which has an array type:
"..the type of the identifier in the declaration T D1 is
"derived-declarator-type-list T", then the type of the identifier of D is
an
array type"

--Semantic quibble. The same meaning applies. The standard and most
--people often conflate identifiers and what they identify. Usually
--there is no ambiguity of meaning. There is no ambiguity of meaning
--here either.

Also the C++ standard states the following:
"5 [ Note: conversions affecting expressions of array type are described
in
4.2. Objects of array types cannot be modified, see 3.10. -end note ]"

So what is this object of array type that cannot be modified?
Both quotes taken form section 8.3.4 Arrays, and easy to find.

--Array objects cannot be (directly) modified, but their sub-objects can
--be modified.

-- int main()
-- {
-- int x[3] = {};
-- int y[3] = {};
-- x = y; //ill-formed
-- x[0] = y[0]; //valid
-- }


So do you accept that this array type object that is non modifiable is not
the same object as the very modifiable 3 integers?

 

[Paul]

That's the *name* of the array that implicitly converts to a pointer.
The name is a compile-time concept, though, and does not quite
correspond to what the Standard calls an "object".

--No. There is an array object, and it is implicitly converted to a
--pointer to the first element. Consider:

-- int x[3];
-- int (*y)[3] = x;
-- int* z = *y;

I think you missed an &, line 2 should be:
int (*y)[3] = &x;

--y is not the identifier of the array object. y is a pointer which
--points to the array object. Derefencing y gives an expression of array
--type, specifically "int[3]". Then a standard conversion sequence is
--applied using the array-to-pointer conversion in the assignment to z.

Anyway so this array object is described in the standard as a non
modifiable
object of array type. SO with :
int arr[5];

arr is an object of array type. Do you agree with this?
--Yes.

and when we do this:
int (*pparr)[5] =&arr;

pparr is a pointer to an object of array type. Do you agree with this?
--Yes.

The array type object

--I don't know what that is. Do you mean object of array type?

What is the difference between an object of array type and an array type
object?
Its the same thing as far as I can tell.

is an object that could be described as a non
modifiable pointer to the array of ints, with added typeinfo to support
C++
references, sizeof and typeid.
Do you agree with this? If not what do you think is wrong about it?

--No it could not be described like that. As has been demonstrated
--before, sizeof(arr) != sizeof(&arr[0]). What makes me think you're
--wrong? A careful reading of the standard, my education, and how all
--compilers are implemented.

I am not satisfied with your reply, I asked you, if you disagreed, to
explain what was wrong about it. You have not explained what you think is
wrong about it.

 

[Paul]

If there is no such thing as an array type object then what is the object
that is implicitly converted to a pointer, and stores a memory address?

--That's the *name* of the array that implicitly converts to a pointer.
--The name is a compile-time concept, though, and does not quite
--correspond to what the Standard calls an "object".

There is an object here that can be converted to a pointer.
The standard describes this object as a non modifiable object of array type.
This object stores the address of the array, and when examined in asm
listings this object is a pointer.
What is it, that is converted to a pointer ?

 

[Joshua Maurice]

The array type object is an object that could be described as a non
modifiable pointer to the array of ints, with added typeinfo to support
C++
references, sizeof and typeid.
Do you agree with this? If not what do you think is wrong about it?

--No it could not be described like that. As has been demonstrated
--before, sizeof(arr) != sizeof(&arr[0]). What makes me think you're
--wrong? A careful reading of the standard, my education, and how all
--compilers are implemented.

I am not satisfied with your reply, I asked you, if you disagreed,  to
explain what was wrong about it. You have not explained what you think is
wrong about it.

I did. It's a definitional issue. You are using words contrary to
their otherwise universally agreed upon definitions. There is no
recourse in this argument besides argument from authority and argument
from consensus, or similar arguments. You are simply wrong. An array
is not simply an immutable pointer. An array object is a region of
memory which contains some number of contiguous (ignoring padding) sub-
objects. There is no magic hidden pointer like what you describe.

I can attempt to persuade you of these definitional facts with the
following program.

#include <iostream>
using namespace std;
int main()
{
int x[3] = {0, 0, 0};
int (*y)[3] = &x;

for (char const* c = reinterpret_cast<char const*>(y);
c != reinterpret_cast<char const*>(y) + sizeof(*y);
++c)
{
cout << (int)*c << " ";
}
cout << endl;
x[1] = 1;
for (char const* c = reinterpret_cast<char const*>(y);
c != reinterpret_cast<char const*>(y) + sizeof(*y);
++c)
{
cout << (int)*c << " ";
}
cout << endl;
}

Consider what this program does. It takes a name of array object "x"
of type "int[3]", takes the address of it "&x", and assigns it to a
pointer "y" of type "int (*)[3]" ala "int (*y)[3] = &x". It then asks
"What does y point to?". It answers it by reading the memory pointed-
to by y, byte by byte, and printing the byte values in decimal to the
screen. It then modifies one of the sub-objects of the array, and then
it re-prints what y points to. On my particular implementation, I got:

0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 0 0 0 0

Thus, y points to 3 contiguous int (sub) objects. There is no magic
hidden immutable pointer which points to the array, nor a magic hidden
pointer which points to the first element of the array. Moreover, this
behavior is required by the standard. There is no UB in my program
(although there is platform specific behavior which will slightly
alter the output from implementation to implementation). Questions?

 

[Paul]

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

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?

The value returned by new.

Which is an address value.

Correct, an int*.

The value returned from new is a pointer value that is an address.

Why do you think it is not an address?

I don't. You changed the context. You originally posted

std::cout<< typeid(*p2).name();

No I originally posted:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
delete[] p1;
std::cout<< *p2<<std::endl;

The code I posted output a memory address.

and asked "what is the object that stores the address and is interpreted
as an array type by the typeid expression?" and I explained that no object
is required for typeid because the type is known at compile time. Did you
understand that?

typeid does not require an object but when it is passed an object it gives
us the type of that object.

 

[Joshua Maurice]

typeid does not require an object but when it is passed an object it gives
us the type of that object.

Only if the static type of the expression is polymorphic. Ex:

int x;
typeid(x);
will say int.

int x;
char* c = reinterpret_cast<char*>(&x);
typeid(*c);
is not UB, and will say char.

struct A { virtual ~A() {} };
A a;
char* c = reinterpret_cast<char*>(&a);
typeid(*c);
is not UB, and will say char.

struct A { virtual ~A() {} };
C c;
A* a = reinterpret_cast<A*>(&c);
typeid(*a);
is UB and may/will crash horribly.

 

[Paul]

The array type object is an object that could be described as a non
modifiable pointer to the array of ints, with added typeinfo to support
C++
references, sizeof and typeid.
Do you agree with this? If not what do you think is wrong about it?

--No it could not be described like that. As has been demonstrated
--before, sizeof(arr) != sizeof(&arr[0]). What makes me think you're
--wrong? A careful reading of the standard, my education, and how all
--compilers are implemented.

I am not satisfied with your reply, I asked you, if you disagreed, to
explain what was wrong about it. You have not explained what you think is
wrong about it.

--I did. It's a definitional issue. You are using words contrary to
--their otherwise universally agreed upon definitions. There is no
--recourse in this argument besides argument from authority and argument
--from consensus, or similar arguments. You are simply wrong. An array
--is not simply an immutable pointer. An array object is a region of
--memory which contains some number of contiguous (ignoring padding) sub-
--objects. There is no magic hidden pointer like what you describe.

No we were talking about the non modifiable object of array type.
You are now talking about a sequence of modifiable objects. Again you revert
back to ignorance of the fact that this object of array type exists.
Forget the modifiable array, and think about the non modifiable object of
array type, what is that object in your own words?


<snip>

 

[Ian Collins]

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

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?

The value returned by new.

Which is an address value.

Correct, an int*.

A memory address value is stored so there must be an object to store
this
value, you say there is no object so what is it that stores this
value?

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

The address is shown in my code above.

The address in your code id the value return by new. No amount of
casting
will change that.

The value returned from new is a pointer value that is an address.

Why do you think it is not an address?

I don't. You changed the context. You originally posted

std::cout<< typeid(*p2).name();

No I originally posted:
pparr p1 = (pparr)new int[3];
pparr p2= p1;
delete[] p1;
std::cout<< *p2<<std::endl;

You conveniently omitted the last line:

std::cout<< typeid(*p2).name();

The code I posted output a memory address.

That is one possible outcome of UB. It could also have output garbage,
or if you have been using one of my specialised x86 debug allocators,
aborted the process.

typeid does not require an object but when it is passed an object it gives
us the type of that object.

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.