Re: Problem with array objects
On 2011-05-23, Paul <pchristor@yahoo.co.uk> wrote:
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnitlb8j.1ruu.aggedor@earl-grey.cloud9.net...
On 2011-05-20, Paul <pchristor@yahoo.co.uk> wrote:
"A. Bolmarcich" <aggedor@earl-grey.cloud9.net> wrote in message
news:slrnitans0.14gr.aggedor@earl-grey.cloud9.net...
On 2011-05-18, Paul <pchristor@yahoo.co.uk> wrote:
[snip]
When you dereference a pointer to int you access the pointed to integer
object like so :
int x=5;
int* px = &x;
std::cout<< *px;
//this will output 5 because dereferencing px accesses the object it points
to.
With an array the situation is not the same becasue an array cannot be
accessed, as a whole. The only way we can point to an array is to point to
one of its elements.
int arr[3] = {1,2,3};
int* parr = arr;
int (*pparr)[3] = &arr;
std::cout<< *parr;
//outputs 1 because it points to the first element of the array.
std::cout<<*pparr;
//outputs a memory address because it points to an array-type object.
The situation with the unary * and unary & operators is the same for
an array and for a non-array. The C++ standard does not specify
different behaviors depending on whether the operand of the unary *
and unary & operators is an array or non-array.
Here is the paragraph from the C++ standard about the unary *
operator.
The unary * operator performs indirection: the expression to which
it is applied shall be a pointer to an object type, or a pointer to
a function type and the result is an lvalue referring to the object
or function to which the expression points. If the type of the
expression is "pointer to T", the type of the result is "T".
[Note: a pointer to an incomplete type (other than cv void ) can be
dereferenced. The lvalue thus obtained can be used in limited ways
(to initialize a reference, for example); this lvalue must not be
converted to an rvalue, see 4.1. ]
The C++ standard does not specify different behaviors for an array
and a non-array with the unary * operator.
Here is the paragraph from the C++ standard about the unary &
operator.
The result of the unary & operator is a pointer to its operand.
The operand shall be an lvalue or a qualified-id. In the first
case, if the type of the expression is "T", the type of the result
is "pointer to T". In particular, the address of an object of type
"cv T" is "pointer to cv T", with the same cv-qualifiers. For a
qualified-id, if the member is a static member of type "T", the
type of the result is plain "pointer to T". If the member is
a nonstatic member of class C of type T, the type of the result is
"pointer to member of class C of type T." [Example:
struct A { int i; };
struct B : A { };
... &B::i ... // has type int A::*
--end example] [Note: a pointer to member formed from a mutable
nonstatic data member (7.1.1) does not reflect the mutable
specifier associated with the nonstatic data member. ]
The C++ standard does not specify different behaviors for an array
and a non-array with the unary & operator.
A difference with array and non-array results is that
array-to-pointer conversion is applied to an array result.
In your example, the statement
int* parr = arr;
implicitly applies array-to-pointer conversion to the array result of
the expression arr. The result of that conversion is a pointer to
the first element of arr, not a pointer to arr. Because parr is a
pointer to int, the result of dereferencing it is an int.
In your example, the statement
int (*pparr)[3] = &arr;
initializes pparr with a pointer to arr, not a pointer to an element
of arr. Because pparr is a pointer to an array of int, the result of
dereferencing it is an array of int. Array-to-pointer conversion is
implicitly applied to that result and the result of the conversion
is a pointer to int that points to the first element of arr.
An array identifier such as 'arr' is an array-type object. A pointer to this
object points to a single object, not to an array of thi sobject type.
The result of using the identifier 'arr' in an expression is an
array. An array is a single object that contains sub-objects. The
expression &arr points to the object that is the array named arr.
Given the declaration
int arr[4];
a C++ implementaion creates an array object to represent the array,
but it does not also create an object that stores a pointer to the
array object, unless one is explicitly present, say due to the
declaration
int (*pparr)[4] = &arr;
Due to that statement a C++ implementation creates a pointer to
array object that is initialized to point to the array. The
pointer points directly to the array object.
The pointer pparr above points to a single object not an array of objects.
Consider this:
int (*p)[3]=0;
std::cout<<*p<<std::endl;
std::cout<< typeid(*p).name()<<std::endl;
std::cout<< sizeof(*p);
Does the above pointer point to a valid object?
Or is it completely UB because its dereferencing a null pointer?
Having the value of a pointer be the null pointer is valid. The
effect of dereferencing the null pointer is undefined.
A few followups ago I posted the code generated by a GNU C++ compiler
to show how an array object and a pointer to an array object were
implemented. I don't know of any compiler that adds an object that
stores a pointer to the array for each array. I don't know of
anything in the C++ standard that requires an object that stores
a pointer to an array for each array. If you do, please provide
details.
An array object must store a pointer otherwise how does it know, where in
memory, the array is?
In a previous post you asked: "So where does the memory address value
come from? Its not stored in the array of integer objects." My
answer was (see
http://groups.google.com/group/comp.lang.c++/msg/90a32f760cdfc958?hl=en)
Where the memory address comes from depends on where the
implementation decides to store the array. For example, an object
with automatic storage duration, such a non-static array declared
in a function, is allocated on the stack in an implementation that
uses a stack for automatic storage.
The compiler knows the compile-time constant offset in the stack
frame where it has decided to store the array. In places where a
program needs the memory address of the array, the compiler puts
in instructions to sum that compile-time constant offset and the
current value of the stack pointer.
In the last sentence, "stack pointer" should have been "stack
frame pointer".
For the program
void foo() {
int arr[4], (*pparr)[4];
pparr = &arr;
}
the assembler output of the GNU C++ compiler for the assignment
statement for an i686 system is
leal -20(%ebp), %eax
movl %eax, -4(%ebp)
The compiler has allocated arr at offset -20 in the stack frame and
pparr at offset -4 in the stack frame. The assembler instructions
store in pparr the sum of -20 and the stack frame address.
Determining the address of arr did not use a value stored in an
object.
[snip]
Avoiding the term "array-type" that you use but the C++ standard
doesn't: the object pointed to by pparr is an array. The type of
the object pointed to is an array of int. As with all arrays in C++,
in some contexts, array-to-pointer conversion is implicitly applied
and the result of the conversion is a pointer to the first element of
the array.
No the C++ standard states its an array type object.
The object pointed to is an array TYPE.
That's right, pparr points to an array type object, an object that
stores an array (the one named arr, in this case). pparr does not
point to an object that stores the address of an array.