More support for Paul's array terminology

[Paul]

On 16/06/2011 20:06, Paul wrote:
int* p1 = new int;
int* p2 = new int[22];
int* p3=0;

p1 points to a single integer, p2 points to an array of integers
and p3
points to nothing at all.

p2 points to the first element of an array of integers; crucially
what
do we say p2 points to if we do:

++p2;

Continuing to say that p2 points to an array when it doesn't point
to
the first element of an array is confusing at best.

No p2 points to an array of integer objects.

I've told you before you can point to a banana in a bunch yet you
also
point to the bunch of bananas at the same time.

You have told all of us your crazy analogies before; crazy analogies
that remain crazy no matter how many times you repeat them or vary
them.

Pointing to a banana is not the same as pointing to a bunch of
bananas.
'p2' is a pointer to a single 'int' not an array of 'int's.

According to the draft standard (and I think it is not likely to
change) p2 is a "pointer to /an/ array" though not a "pointer to
array". Likewise, ++p2 is also a "pointer to /an/ array" that so
happens to also be a sub-array.

So, unless the standard changes, your opinion directly conflicts
with it; you are wrong and Paul is consistent with the standard.

And according to the draft C standard the term "pointer to an array"
is what the draft C++ standard refers to as a "pointer to array". I am
of the opinion that the draft C++ standard is in error changing the
meaning of "pointer to an array": try applying some common sense.

int *p = 0; // pointer to int, pointer to an int

No , this pointer points to nothing. It can be said it is of "type
pointer to int", which is often shortened to "pointer to int".
The context of this is not the same a what is pointed-to, this context
is referring to the pointers type, or what the pointer is.

int (*pa) = 0; // pointer to array, pointer to an array

Again this pointer points to nothing.
You are confusing the term "is a pointer to ..whatever", with the
context of what is pointed-to and what type the pointer is.

You are the one confusing what type of pointer a pointer is and the
dynamic type of any object that is pointed to. In the case of arrays a
pointer to an element (sub-object) of an array object is not a pointer to
an array; there is a similar situation for class types:

base* pb = 0;

'pb' is a pointer to a base even if the dynamic type of the object pointed
to is derived from base.

You need to stop confusing runtime concepts with compile time concepts.

A pointer points-to whatever it points to, whether it be runtime or compile
time.
A pointers type is a different thing from what it points-to.

In your example pb points to nothing , it is a null pointer and it does not
point to any object whether you are thinknig about compile or runtime.
Its type is "pointer to base", this does not mean it points to a base.

Again you are confusing runtime with compile time.

No it points-to nothing in compile time and runtime.

Yes compile time and runtime are different contexts and if it is not
obvious which context is meant then the context should be made explicit.


What you are saying is gibberish as it is not clear what you mean by
"pointer to the array" as you like to confuse compile time and runtime
contexts/concepts in an almost arbitrary fashion to try and suit your
argument at a particular moment in time.

No its clear that a pointer to an array is a pointer that...drumroll
...points to an array.

int* p = some_opaque_function(); // 'p' is a pointer to an int
int (*p)[42] = some_opaque_function(); // 'p' is a pointer to an array of
int

As you can see the default position of assuming a compile time context
(static type) is the most sensible position.

No its not the most sensible, it is one of two different views.
Pre-compiled code wouldn't be very sensible if there was no runtime in which
to run the program.

This is where you are wrong, your view is that one context is correct and
the other is not , but they are both correct.

 

[Paul]

No its not the most sensible, it is one of two different views.
Pre-compiled code wouldn't be very sensible if there was no runtime in
which to run the program.

Correction:

Pre-compile time code.

 

[Paul]

int* p = some_opaque_function(); // 'p' is a pointer to an int
int (*p)[42] = some_opaque_function(); // 'p' is a pointer to an array
of int

As you can see the default position of assuming a compile time context
(static type) is the most sensible position.

No its not the most sensible, it is one of two different views.
Pre-compiled code wouldn't be very sensible if there was no runtime in
which to run the program.

This is where you are wrong, your view is that one context is correct
and the other is not , but they are both correct.

What you are saying is false: I am not saying the the other context is
incorrect at all; I am saying that *without* an explicit context the term
"pointer to an array" can either mean only one thing or it is completely
ambiguous and shouldn't be used at all.

Without a context it can obviously mean more than one thing. The term can be
referring to the type of the pointer, what it points-to, or even to the type
of object it points to.

p is of type pointer-to-int. (referring to the type of pointer)
p is a pointer-to an int-type-object. (referring to the type of the pointed
to object)
p is a pointer to int. (does not imply the type of the pointer or the
pointed to object, it's a general statement about what p points-to).


Note the last statement can be plural or singular , i.e:
p is a pointer to an int.
p is a pointer to int's.

 

[Paul]

yes, for what it count; a pointer can safety? point to the middle
of one object for example
int a;
char *b;
b=&a; ++b;

So basically you'd be treating 'a' as an array of bytes.

This is ok if it works on your system but I would excercise caution because
it may work on one system but not on another.
Endienness and other addressing factors must be suitable for this to work I
guess, I would be carefull about this.

that contain data. A pointer of type int* can point to integer objects,
or
nothing at all.

int* p1 = new int;
int* p2 = new int[22];
int* p3=0;

p1 points to a single integer, p2 points to an array of integers and p3
points
to nothing at all.

p3 point to address 0 in the memory

I think this value is used to represent a null pointer because it is not
a
valid addressable address. I agree that in some contexts the pointer can
be
seen to point to the address 0 but remember that a pointers' value is not
always a real address and it may be added to a base pointer where the
result
would not be address 0 in memory.

special address example, 0,-1,1,2 i think could be think as error address
to return from function that fail; but i think in C and C++ only 0 or NULL
is-shold be- safe for return

Note: 0 may be a valid address on some system. IDK.

yes but someone can consider it as error address too
even if it exist and is possible to read and write to it

I agree, it is highly doubtfull that such a system exists anyway.

 

[Keith H Duggar]

On 16/06/2011 23:05, Paul wrote:
On 16/06/2011 20:06, Paul wrote:
int* p1 = new int;
int* p2 = new int[22];
int* p3=0;
p1 points to a single integer, p2 points to an array of integers and p3
points to nothing at all.
p2 points to the first element of an array of integers; crucially what
do we say p2 points to if we do:
++p2;
Continuing to say that p2 points to an array when it doesn't point to
the first element of an array is confusing at best.
No p2 points to an array of integer objects.
I've told you before you can point to a banana in a bunch yet you also
point to the bunch of bananas at the same time.
You have told all of us your crazy analogies before; crazy analogies
that remain crazy no matter how many times you repeat them or vary them.
Pointing to a banana is not the same as pointing to a bunch of bananas..
'p2' is a pointer to a single 'int' not an array of 'int's.

According to the draft standard (and I think it is not likely to
change) p2 is a "pointer to /an/ array" though not a "pointer to
array". Likewise, ++p2 is also a "pointer to /an/ array" that so
happens to also be a sub-array.

So, unless the standard changes, your opinion directly conflicts
with it; you are wrong and Paul is consistent with the standard.

And according to the draft C standard the term "pointer to an array"
is what the draft C++ standard refers to as a "pointer to array".

This is a C++ newsgroup. The topic of discussion is C++. If you
want to troll about C you are in the wrong forum.

I am of the opinion that the draft C++ standard is in error

I am sure you feel that way. However, until the standard changes
the /fact/ remains that Paul's terminology is consistent with the
standard. In /fact/, Paul's terminology is used /verbatim/ in the
standard exactly as Paul uses it.

changing the meaning of "pointer to an array":

It's not "changing the meaning" as pretty everyone except you has
no trouble whatever understanding the phrase "pointer to an array"
in a context referring to the /value/ (not the type) of a pointer.

try applying some common sense.

lolz ... oh the irony.

int *p = 0;  // pointer to int, pointer to an int

Wrong. Correct is "pointer to int, pointer to an undefined".

int (*pa) = 0; // pointer to array, pointer to an array

Wrong. Correct is "pointer to int array, pointer to an undefined".

As these two standards disagree on terminology

This is a C++ newsgroup. The topic of discussion is C++. If you
want to troll about C you are in the wrong forum.

I would say that you are being premature saying that we are
incorrect

"We"? lolz ... by all means keep deluding yourself.

As for being premature, it's only premature because the draft has
not yet been promoted to an approved standard. Once it has been,
well, I'm afraid you will be s.o.l (unless it changes) as far as
this particular personal flame war of yours with Paul goes.

and that you two trolls who happen to agree with each other
are correct.

The phrase is used /verbatim/ in the draft C++ standard exactly
as Paul uses it. Good luck fighting an international standard.
Your only chances are (1) switch to another programming language
(2) successfully lobby to have the wording of the standard to ...
what exactly? How would you, Leigh, rewrite this section:

27.7.5
...
template <class charT> unspecified get_time(struct tm* tmb, const
charT* fmt);

7 Requires: The argument tmb shall be a valid pointer to an
object of type struct tm, and the argument fmt shall be a valid
/pointer to an array/ of objects of type charT with
char_traits<charT>::length(fmt) elements.

of the standard? (By the way, do make sure to keep in mind your
previous ranting about sub-arrays not being arrays.)

KHD