Pointer Problem

[Paul]

On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote:
A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need
two multipliers it only needs one. This is not "loss of information"
as you have put it, the information is not there because it's not
required.
I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array.  It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects.  How do you sensibly increment a pointer without knowing the range of values the pointer can logically take?
An example:
An example:
int a[10];
int (&b)[9] = a[1];
The C++ language dictates that this is illegal syntax, despite the fact that simple analysis shows that it is perfectly reasonable and logically correct.  This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support.
No I never brought references into the discussion.,
References *are* pointers...

But you have said yourself that a pointer does not carry typeinfo. You
are contradicting yourself by saying that a reference is a pointer,
when it suits you.

If you insist:
int a[10];
int (*b)[9] =&a[1];
The argument still holds...
Given only
int* iptr = something();
I wish you wouldn't use this default object construction syntax(or
function syntax) when assigning to pointers, because more often than
not this will not return an objects' address. An objects' address is
assigned to a pointer, not an object.
I'm not sure why you'd think it was an object constructor call -- it makes more syntactic sense as a simple function call.  In any case, it's pseudo-code.  The RHS of the assignment is not relevant which is why I didnot work very hard at making it realistic.  The point being: A _naked_ pointer cannot be (usefully) treated as an array reference.
A pointer doesn't only point to an object or null because it can also
point to objects(plural).
It can point to an object allocated as part of an array, yes.

No , it can point to objects(plural) , that is what I said objectS
(plural) , not a single object that is part of something.

You don't always need information, its a well known fact that in C and
C++ a pointer to an array does not carry size information.
All allocations aren't arrays , because an array is a sequence of
elements. Yes an array of size 1 is the same as a single object but
then that's not really an array is it, its just a single object. And
please don't  bring arrays of size 0 into the discussion..

Leighs argument is that an int* can only point to a single int and
cannot point to an array of ints. This contradicts what Bjarne says in
his C++ glossary re: "char* - pointer to a char or an array of char"
source:http://www2.research.att.com/~bs/glossary.html.

This is why I am objecting to Juha and Leighs argument because they
are confusing the pointers-type with what is pointed-to. The two are
different contexts of  "is a pointer -to" and not always related.

If we have an object in memory that is an array, of any size: A
pointer to it is a pointer to an array regardless of its's type, or to
where it points within the array. They are incorrect to suggest that
what is pointed to is defined by the pointers type, just look at a
void pointer for an example of how wrong this is.

Your void pointer argument is a straw man.  It is really quite simple if
you think in terms of objects: a void* pointer can point to an object of
any type or nothing at all; an int* pointer can point to an object of
type int or nothing at all.

Nope, a pointer can point to an object, objects or nothing.

If an int* pointer points to an object of type int which is part of an
array it is incidental that it is part of an array: it still points to
the array element not the array.

This is plain narrow mindedness.
The way to understand it is that the int* points to int
objects(plural).

When talking about C++ types and objects are probably the most important
things to consider.

The type of objects pointed to are int type objects, thus it's common
sense that you'd use an int* to point to them.

Why would you use a pointer of type(*)[10] to point to a 1-dim array
of 10 ints? The extra [10] on this pointer type does nothing to affect
the pointed-to array, it only affects the way its incremented and
indexed. The main thing about this pointer type is that it has another
level of indirection. You cannot index it without an addition
dereference. You cannot increment it with first dereferencing it. It
has an extra level of indirection that is completely unnecessary.

 

[Paul]

On 27/02/2012 16:17, Paul wrote:
On Monday, February 27, 2012 8:07:58 AM UTC-6, Paul wrote:
A 1-dim array doesn't need a multiplier. A 2-dim array doesn't need
two multipliers it only needs one. This is not "loss of information"
as you have put it, the information is not there because it's not
required.
I'm not talking about multipliers, I'm talking about knowing the bounds of the underlying array.  It is lost information and it is required if you want to (robustly) treat the pointer as a reference to an array of objects.  How do you sensibly increment a pointer without knowing the rangeof values the pointer can logically take?
An example:
An example:
int a[10];
int (&b)[9] = a[1];
The C++ language dictates that this is illegal syntax, despite thefact that simple analysis shows that it is perfectly reasonable and logically correct.  This is the sort of 'context' you've been referring to but this 'context' is exactly what the language does not support.
No I never brought references into the discussion.,
References *are* pointers...
But you have said yourself that a pointer does not carry typeinfo. You
are contradicting yourself by saying that a reference is a pointer,
when it suits you.
If you insist:
int a[10];
int (*b)[9] =&a[1];
The argument still holds...
Given only
int* iptr = something();
I wish you wouldn't use this default object construction syntax(or
function syntax) when assigning to pointers, because more often than
not this will not return an objects' address. An objects' address is
assigned to a pointer, not an object.
I'm not sure why you'd think it was an object constructor call -- itmakes more syntactic sense as a simple function call.  In any case, it'spseudo-code.  The RHS of the assignment is not relevant which is why I did not work very hard at making it realistic.  The point being: A _naked_pointer cannot be (usefully) treated as an array reference.
A pointer doesn't only point to an object or null because it can also
point to objects(plural).
It can point to an object allocated as part of an array, yes.
No , it can point to objects(plural) , that is what I said objectS
(plural) , not a single object that is part of something.
   Beyond that, you need external information.  If you want tobe pedantic about it, you could say that all allocations are array allocations just that many of them are arrays of size 1.  Does it change what you can do with>pointers?  Nope.  Does it change the meaning of pointers? Nope.
You don't always need information, its a well known fact that in C and
C++ a pointer to an array does not carry size information.
All allocations aren't arrays , because an array is a sequence of
elements. Yes an array of size 1 is the same as a single object but
then that's not really an array is it, its just a single object. And
please don't  bring arrays of size 0 into the discussion..
If you agree with Leighs argument , and disagree with Bjarne S, then I
think you have missed the point
I'm not sure what you think Leigh's argument is at this point.  I see nothing that contradicts anything Bjarne has ever said.  I still contend you are in violent agreement.
Leighs argument is that an int* can only point to a single int and
cannot point to an array of ints. This contradicts what Bjarne says in
his C++ glossary re: "char* - pointer to a char or an array of char"
source:http://www2.research.att.com/~bs/glossary.html.
This is why I am objecting to Juha and Leighs argument because they
are confusing the pointers-type with what is pointed-to. The two are
different contexts of  "is a pointer -to" and not always related.
If we have an object in memory that is an array, of any size: A
pointer to it is a pointer to an array regardless of its's type, or to
where it points within the array. They are incorrect to suggest that
what is pointed to is defined by the pointers type, just look at a
void pointer for an example of how wrong this is.
Your void pointer argument is a straw man.  It is really quite simple if
you think in terms of objects: a void* pointer can point to an object of
any type or nothing at all; an int* pointer can point to an object of
type int or nothing at all.

Nope, a pointer can point to an object, objects or nothing.

This is plain narrow mindedness.
The way to understand it is that the int* points to int
objects(plural).

Wrong; a pointer can only ever point to one object at a time.  If a int*
pointer pointed to the middle element of an array you couldn't pass this
pointer to delete[] to delete the array (you can only pass a pointer to
the initial element of an array to delete[]) so it is wrong to say that
this pointer points to an array and it is correct to say that this
pointer points to an array element.

No this is where you are wrong. A pointer can point to one past the
end of an array and thus it points to no individual objects.

Delete requires a pointer that have the same value returned from the
matching allocation by new. The allocation of a dynamic array returns
a pointer to an array of objects, which also happens to be a pointer
to the initial element. Saying that it's a pointer to the initial
element but not a pointer to the array is complete nonsense.

Except an int* pointer can only point to one int object at a time.

No this is rubbish an int* can point to an array of int objects.

Why would you use a pointer of type(*)[10] to point to a 1-dim array
of 10 ints? The extra [10] on this pointer type does nothing to affect
the pointed-to array, it only affects the way its incremented and
indexed. The main thing about this pointer type is that it has another
level of indirection. You cannot index it without an addition
dereference. You cannot increment it with first dereferencing it. It
has an extra level of indirection that is completely unnecessary.

You use the appropriate type for the job at hand. You can invoke
array-to-pointer conversion to obtain a pointer to the first element of
an array so talking about levels of indirection is mostly a smoke screen
of your own making.

It's not a smoke screen its a fact that the following pointers to
arrays all increase in levels of indirection:
int*
int(*)
int(*)[S1][S2]
int(*)[S1][S2][S3]
All the above pointers can point to arrays of integer objects. The
difference is in their level of indirection, which defines the number
of dimensions in the pointed-to array.

With the simple example of:
int arr[10];
int* p1 = arr;
int(*p2)[10] =&arr;

If we dereference p1 we access the array because it is the directly
pointed-to object:
*p1 = 66;
And we can increment the array to access the next element:
p1++;
*p1 = 77;

With p2 we need to dereference twice to access the array:
**p2 = 66;
Incrementing this requires more dereferencing:
*((*p2)+1)= 77;
Another way to access the array is to use 2-dim array notation:
p2[0][1] = 77;

Thus it makes sense that p1 is more suitable as a pointer to a 1-dim
array and p2 more suitable as a pointer to a 2-dim array.
Both pointers are objects that hold exactly the same memory address,
to suggest that they point to different objects is complete nonsense.

 

[Paul]

Wrong; a pointer can only ever point to one object at a time.  If a int*
pointer pointed to the middle element of an array you couldn't pass this
pointer to delete[] to delete the array (you can only pass a pointer to
the initial element of an array to delete[]) so it is wrong to say that
this pointer points to an array and it is correct to say that this
pointer points to an array element.

No this is where you are wrong. A pointer can point to one past the
end of an array and thus it points to no individual objects.

Yes a pointer can point to one past the end of an array and this does
not contradict what I have said.

So when you say "a pointer can only point to one object at a time". To
which object does it point when it points to one past the end of an
array?

The only time it is conceivably safe to say that a pointer points to an
array is when that pointer does indeed point to the first element; if it
points to any other part of an array (or one past the end) it is simply
confusing to say that it points to an array.

I don't see why? If you passed a pointer into a function to iterate
through an array or something. I wouldn't like to think that if the
pointer was incremented it no longer points to the array.

Obviously the idea that an int* pointer can point to more than one int
object at a time is "rubbish".

Why is it rubbish?
You cannot point to one single banana , in a bunch , without also
pointing at the bunch.
It's purely contextual , are you pointing to a group of objects, at an
individual object, or can both be correct.

Why would you use a pointer of type(*)[10] to point to a 1-dim array
of 10 ints? The extra [10] on this pointer type does nothing to affect
the pointed-to array, it only affects the way its incremented and
indexed. The main thing about this pointer type is that it has another
level of indirection. You cannot index it without an addition
dereference. You cannot increment it with first dereferencing it. It
has an extra level of indirection that is completely unnecessary.
You use the appropriate type for the job at hand. You can invoke
array-to-pointer conversion to obtain a pointer to the first element of
an array so talking about levels of indirection is mostly a smoke screen
of your own making.

It's not a smoke screen its a fact that the following pointers to
arrays all increase in levels of indirection:
int*
int(*)
int(*)[S1][S2]
int(*)[S1][S2][S3]
All the above pointers can point to arrays of integer objects. The
difference is in their level of indirection, which defines the number
of dimensions in the pointed-to array.

With the simple example of:
int arr[10];
int* p1 = arr;
int(*p2)[10] =&arr;

If we dereference p1 we access the array because it is the directly
pointed-to object:
*p1 = 66;
And we can increment the array to access the next element:
p1++;
*p1 = 77;

With p2 we need to dereference twice to access the array:
**p2 = 66;
Incrementing this requires more dereferencing:
*((*p2)+1)= 77;
Another way to access the array is to use 2-dim array notation:
p2[0][1] = 77;

Thus it makes sense that p1 is more suitable as a pointer to a 1-dim
array and p2 more suitable as a pointer to a 2-dim array.
Both pointers are objects that hold exactly the same memory address,
to suggest that they point to different objects is complete nonsense.

Wrong again.  Explain why sizeof(*p1) != sizeof(*p2).  An array is an
object and an array element is a sub-object.  From n3337:

What exactly are you trying to say is wrong here?
Why compare sizeof(an array element) with sizeof(a reference), does
this somehow disprove the fact that the pointers are different levels
of indirection?

"Objects can contain other objects, called subobjects. A subobject can
be a member subobject (9.2), a base
class subobject (Clause 10), or an array element. An object that is not
a subobject of any other object is
called a complete object."

p1 points to an array element which is a sub-object of what p2 points
to; the fact that they may have the same address is incidental to the
semantics of pointers of specific types.

This cannot happen in C++ because, although it supports OOP, its not a
pure OOP language.

An array object of type int[10] is not something that can be pointed
to, as a whole. You can only ever point to element type objects.
Dereferencing p2 yields a pointer, or a reference depending on usage.
You can only access the array by dereferencing p2 twice, then you will
only access one of the arrays elements.