An array is just a pointer

[Paul]

On 21/03/2011 18:40, Paul wrote:
On 21 Mrz., 02:00, Paul wrote:

Or alternatively they could simply compile and run the following
code:

template<typename T>
void foo(T p){
std::cout<< "\nIn primary foo:\t" << typeid(T).name();
}

template<>
void foo<int*>(int* p){
std::cout<< "\nIn specialized foo:\t" << typeid(p).name();
}

int main(){
const int s = 2;
int p1[1];
int p2;
foo(p1); // #1
foo(p2); // #2
}

--I guess you intended to prove "an array is just a pointer"
again.
-- But

I never have tried to prove this, but nonetheless for all
intensive
purposes that's how the language works.

What I have been arguing is againt the idiots who suggest p is
not a
pointer to an array, with:
int* p= new int[16];

--this code example only shows that template argument deduction
picks
--T=int* respectivly T=int(*)[2]. It does not prove that the
arrays
--denoted by p1 and p2 are pointers. If you think otherwise, look
up the
--term "array-to-pointer decay" and check out the template
argument
--deduction rules in the C++ ISO standard.

--BTW: Are you aware of the following?

-- template<class T>
-- void foo(T & ref);
-- :
-- :
-- foo(p1); // --> T = int[1], T& = int(&)[1]
-- foo(p2); // --> T = int[2][2], T& = int(&)[2][2]

--In both cases T& is the type of a reference to an _array_, not a
--_pointer_.

A reference to an array of int:
int (&r)[5]
is the same type as int* p, not int(*p)[5].

Are you one of those who think p is not a pointer to an array
because a
pointer to an array must be type int(*)[SIZE] ?

If you want conclusive proof simply use a specialized traits
template:

template<typename T, typename T1>
struct is_same_type{
enum {value = 0};
};
template<typename T>
struct is_same_type<T,T>{
enum {value = 1};
};

template<typename T1, typename T2>
void foo(T1 p1, T2 p2){
if(is_same_type<T1, T2>::value) std::cout<< "Types are the
same\n" ;
else std::cout<< "Types are different\n";
}

int main(){
int arr[5]={0};

int* p1 ='\0';
int (*p2)[5] ='\0';
int (&r)[5] = arr;


foo(arr, p1); //Same type
foo(arr, p2); //Different type
foo(arr, r); //Same type
foo( r, p1); //Same type
foo( r, p2); //Different type
}


Tuition fees extra , TYVM and goodbye .
Have a nice day.


You have proven nothing:

template<typename T>
void foo(T v)
{
std::cout<< "Not an array\n";
}
v's type could be any type: an array of types, a pointer to an
array ,
or an array of function pointers.

No it couldn't given the other overload below which will be used for
arrays.

I'm afraid once again I must prove you wrong:

#include <iostream>
template<typename T>
void foo(T v)
{
std::cout<< "\nAn object of type:\t" << typeid(T).name() << " <- Not
an
array?\n" ;;
}

template <typename T, std::size_t S>
void foo(T (&a))
{
std::cout<< "\nAn array of type:\t" << typeid(T).name();
}

int main()
{
int arr[6];
int (*parr)[6] = new int[5][6];
foo(arr);
foo(parr);
}


It's about time you learned to accept defeat.

You fail yet again. A "pointer to an array" is not the same as an
"array".

It's not a pointer to an array though, The object pointed-to is an array
of pointers to arrays (a 2dim array). This is what you do not seem to
understand.

No it is not an array of pointers; there is only one pointer namely the
pointer to the array which is itself not an array as it is .. wait for
it .. a pointer. So you fail yet again; you are a lost cause.

#include <iostream>
template<typename T>
void foo(T v)
{
std::cout<< "\nAn object of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (&a))
{
std::cout<< "\nAn array of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (*a))
{
std::cout<< "\nA pointer to an array of type:\t" << typeid(T).name();

This is wrong, it produces the output:
"A pointer to an array of type: int" .
The object pointed to is a 2dim array of type int(*).
Your code cannot tell the difference between 1dim arrays and 2dim
arrays.

As far as the ambiguity of the template overloads is concerned this is
just a feature of the fact that arrays can decay to pointers. Just
because arrays can decay to pointers does not mean that arrays are
pointers.

SO your template system cannot define between a 1dim array and a 2diim
array? You just treat a 2dim dynamic array is if it were a 1dim array of
pointers.

 

[Paul]

[...]

#include <iostream>
template<typename T>
void foo(T v)
{
std::cout<< "\nAn object of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (&a))
{
std::cout<< "\nAn array of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (*a))
{
std::cout<< "\nA pointer to an array of type:\t" << typeid(T).name();

This is wrong, it produces the output:
"A pointer to an array of type: int" .
The object pointed to is a 2dim array of type int(*).
Your code cannot tell the difference between 1dim arrays and 2dim
arrays.

As far as the ambiguity of the template overloads is concerned this is
just a feature of the fact that arrays can decay to pointers. Just
because arrays can decay to pointers does not mean that arrays are
pointers.

template<typename T, std::size_t S>
void is_an_array(T (&a)) {}

template<typename T, std::size_t S1, std::size_t S2>
void is_an_array(T (&a)[S1][S2]) {}

template<typename T, std::size_t S>
void is_a_pointer(T (*a)) {}

int main()
{
int a[42][42];
int (*pa)[42] = new int[42][42];
is_an_array(a);
// is_an_array(pa); // won't compile if uncommented as a pointer is not an
array

Pardon? pa definately points to a 2d dynamic array object.
the type of pa is:
int (*)[Size];
Surely in even the most unreasonable mind it has to be some sort of array.
You can't now say it's a pointer to a single element and not an array so are
you suggesting the C++ language, or at least your compiler, is wrong and not
you.?

...

is_a_pointer(a); // array decays to a pointer (does not mean that array is
a pointer)

The correct terminology is "deduced".

 

[Paul]

For this particular case, Stroutstup was very clear in his wording
with
his
series of examples in TCPPPL 5.3 Pointers into Arrays without
being
ambiguous,
or overly pedantic.

int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element

++p1; //pointer to 2nd element
++p1; //pointer to 3rd element
++p1; //pointer to 4th element
++p1; //pointer to no elements

p1 is a pointer to the array no matter what element it points to.

This statement is even less correct than others that you've made.

Why? becuase you say so?

This isn't about my beliefs or my opinions. I have authoritative
sources
that
state the case clearly in favor of my position and not yours.

Please reveal these secret authorative sources that you claim to have.

I've already revealed them in this very thread. You're just too busy
snipping
and "quickscanning" to use your own wording.

All you posted was the folowing:

<quote ref= "your authorative source">
int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element
</quote>

In what way do you interpret this to mean that p1 or p2 are not pointers
to
an array?

Because it is explicitly stated that p1 and p2 are pointers to a single
element.
A single element is in fact not the same as an array.
Had the author thought it pertinent to agree with your case, he would have
by
now.

If it points to an element in the array then , by definition, it points to
the array.
He is specifying to where in the array it points , not that it doesn't point
to the array.

As I already told you you could do
++p; //pointer to second element
++p // pointer to third element
etc etc.

This doesn't mean he is wrong to say it points to the first element or I am
wrong to say it now points to the third element. This means the pointer to
the array can point to any element ,or one past the end, as per the C++
standards.

It is your language that continuously needs interpreting as many others
have
told you.

So you are both forgetful and ignorant. Here are your exact words, "The
rest of
your post just just further proves you don't have a clue about
the C++ langauge.
<snip> "

I think you are the one being ignorant.

Your code does not simplify, elaborate upon, or extend the meaning of
Stroustrup's code. In fact, there is no simpler version of Stroupstup's
example
that encompasses your misuse of language and terminology which is why I
cited
it.

Stroustrup doesn't say... the pointer is to a single element and not a
pointer to the array.
All he says is it points to the initial element, that doesn't mean it
doesn't also point to the array. In fact quite the opposite it can't not
point to the array if it points to an element and I'm sure BS would agree.

Then not only are you forgetful and ignorant, you seem to not be able to
count.
But i guess this can also come under ignorance. Nearly 100% of the
responses to
your posts have "gone against" your way of communcation and your use of
language.

Yes but look on the internet at almost every rellevant C++ document.
Almost every C++ user in the world, except you and a few others in here,
use the same terminology as me . That is with:

int p = new int[10];

p is a pointer to an array. If you disagree you are in the minority . thats
a fact.

You can repeatedly continue to deflect the obvious cure for your ailment,
which
would simply be to cite a single example from an authoritative source that
is
congruent to your position with regards to what a pointer is and what it
points
to in the context of the basic example in this thread, but you cannot and
I am
certain that you will continue to make up reasons as to why you can't.

Furthermore, this is not a competition of any kind. Starting threads with
the
title, "Owned" or "Proven Wrong" is as equally unimpressive as starting a
thread
with a false statement such as, "An array is just a pointer".

That was the subject for debate , not a statement of fact, as it was in the
*drumroll* subject field.

You are VERY immature with your social skills and mental reasoning skills
as you
have proven all by yourself. This has led to a pervasive effect on others
who
have tried to help you.

And after all is said, you will continue to deflect without logic or
citation.

Yeah yeah whatever. I'm an immature 57 year old.

 

[Paul]

[...]

#include <iostream>
template<typename T>
void foo(T v)
{
std::cout<< "\nAn object of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (&a))
{
std::cout<< "\nAn array of type:\t" << typeid(T).name();
}

template <typename T, std::size_t S>
void foo(T (*a))
{
std::cout<< "\nA pointer to an array of type:\t" <<
typeid(T).name();

This is wrong, it produces the output:
"A pointer to an array of type: int" .
The object pointed to is a 2dim array of type int(*).
Your code cannot tell the difference between 1dim arrays and 2dim
arrays.


As far as the ambiguity of the template overloads is concerned this is
just a feature of the fact that arrays can decay to pointers. Just
because arrays can decay to pointers does not mean that arrays are
pointers.


template<typename T, std::size_t S>
void is_an_array(T (&a)) {}

template<typename T, std::size_t S1, std::size_t S2>
void is_an_array(T (&a)[S1][S2]) {}

template<typename T, std::size_t S>
void is_a_pointer(T (*a)) {}

int main()
{
int a[42][42];
int (*pa)[42] = new int[42][42];
is_an_array(a);
// is_an_array(pa); // won't compile if uncommented as a pointer is
not an array

Pardon? pa definately points to a 2d dynamic array object.
the type of pa is:
int (*)[Size];
Surely in even the most unreasonable mind it has to be some sort of
array.
You can't now say it's a pointer to a single element and not an array so
are you suggesting the C++ language, or at least your compiler, is wrong
and not you.?

How many times do people have to drill this into you? A POINTER TO AN
ARRAY IS NOT AN ARRAY IT IS A POINTER.

What "pa" actually points to is irrelevant; the *type* of "pa" is a
pointer to a 1d array of type int[42]; an object's *type* defines what an
object *is*.

It is a 2dim array. How can this not be a pointer to a dynamic array?

int (*pa)[42] = new int[42][42];


Come on?. Tell me how , even in the densest of pea-like brains like yours,
this cannot be a pointer to an array?

No the correct terminology is "array-to-pointer conversion" which also
happens in non template contexts.

No the correct terminology is deduced.

 

[James Kanze]

[...]

The C++ standard explicitly says that one of the operands to []
must be a pointer, and the other must have an integral type. No
array allowed.
I'd suggest that you read the standard.

I suggest you stop speaking such utter bool.

I'll repeat my suggestion. Read the C++ standard. And show me
where it defines an operator[] on an array.

[...]

int* array = new int[16];
int* arr2 = new (array + 1) int[15];
That second line constructs a new array, of 15 elements, and
returns a pointer to the first element. You cannot subtract
anything from arr2 until you've incremented.
We're talking about a pointer in C++. And in
C++, pointers have a type, and can only point to that type.

No they point to objects in memory.

And objects have a type. Always. And in C++, a pointer points
to a specific type, and cannot point to object of any other
type. (There are a few special exceptions for char pointers.)

That's why pointer values are memory addresses.

At the hardware level. But we're talking here about C++, and
not hardware pointers.

It's an arrangement of memory elements in one or more planes.

There are no planes in C++. An array is a sequence of objects,
all of the same type. (It's also an object in its own right.)

[...]

int* arr1 = new int[12]; /*Create an array of 12 int*/
arr1[0] = 33;
int* arr2 = new(++arr1) int[11]; /*Create an sub-array within original*/

You see. You even say so: new int[11] creates a new array of 11
ints, and returns a pointer to the first element of that array.
Not a pointer to arr1.

No I said I created an array of 12 ints, then I create and
sub-array within it, which returns a pointer with a value
identical to that of arr1.

You didn't create a subarray. You created a new array, using
some of the memory of the old one. (C++ doesn't have
"subarrays", although I guess you could call an array which is a
subobject of some larger object a subarray. That's not the case
here, however.)

std::cout<< arr2[-1]; /*Access the original array using the sub-arrays
pointer*/

arr2 doesn't point into the first array; it points into the
array you created with the new expression which you used to
initialized arr2.

arr2 and arr1 both point to the same memory location.

So? The same memory location can be used for different objects
at different times.

But the subobjects , which are in themselves little complete
objects, that extend beyond the overwritten memory survive
the overwrite operation. So they were spared certain death by
the ending of their lifetime.

That's an interesting question, and I don't think that the C++
standard is clear about it. In this case, however, the only
subobjects of an array are its elements. Given your new
(++arr)int[11], if subobjects continue to exist, the first
element of arr is still valid. But the others aren't.

I'm not too bothered about where definitions are in the standard,

But that's what defines C++.

I know its simply ridiculous to suggest you cannot index an
array in C++ and I don't intend wasting my time looking for
definitons to present to you for unreasonable responses.

I tend to agree that it's ridiculous that you cannot index into
an array---that in C++, the [] operator is only defined for
pointers, not for arrays. But that's the way it is. C++ has
inherited some fairly ridiculous characteristics from C.

Well it does index then if you have any clue what array indexing is.

But it doesn't if you understand C++.

 

[ghartshaw]

On 21/03/2011 22:42, Paul wrote:

[...]
#include <iostream>
template<typename T>
void foo(T v)
{
std::cout<< "\nAn object of type:\t" << typeid(T).name();
}
template <typename T, std::size_t S>
void foo(T (&a))
{
std::cout<< "\nAn array of type:\t" << typeid(T).name();
}
template <typename T, std::size_t S>
void foo(T (*a))
{
std::cout<< "\nA pointer to an array of type:\t" <<
typeid(T).name();
This is wrong, it produces the output:
"A pointer to an array of type: int" .
The object pointed to is a 2dim array of type int(*).
Your code cannot tell the difference between 1dim arrays and 2dim
arrays.
As far as the ambiguity of the template overloads is concerned this is
just a feature of the fact that arrays can decay to pointers. Just
because arrays can decay to pointers does not mean that arrays are
pointers.
template<typename T, std::size_t S>
void is_an_array(T (&a)) {}
template<typename T, std::size_t S1, std::size_t S2>
void is_an_array(T (&a)[S1][S2]) {}
template<typename T, std::size_t S>
void is_a_pointer(T (*a)) {}
int main()
{
int a[42][42];
int (*pa)[42] = new int[42][42];
is_an_array(a);
// is_an_array(pa); // won't compile if uncommented as a pointer is
not an array
Pardon? pa definately points to a 2d dynamic array object.
the type of pa is:
int (*)[Size];
Surely in even the most unreasonable mind it has to be some sort of
array.
You can't now say it's a pointer to a single element and not an array so
are you suggesting the C++ language, or at least your compiler, is wrong
and not you.?

How many times do people have to drill this into you?  A POINTER TO AN
ARRAY IS NOT AN ARRAY IT IS A POINTER.

What "pa" actually points to is irrelevant; the *type* of "pa" is a
pointer to a 1d array of type int[42]; an object's *type* defines what an
object *is*.

It is a 2dim array. How can this not be a pointer to a dynamic array?

 int (*pa)[42] = new int[42][42];

Come on?. Tell me how , even in the densest of pea-like brains like yours,
this cannot be a pointer to an array?

No the correct terminology is "array-to-pointer conversion" which also
happens in non template contexts.

No the correct terminology is deduced.

From n3242:

4.2 Array-to-pointer conversion [conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown bound of T" can be
converted to a prvalue of type "pointer to T". The result is a pointer to the first
element of the array.

 

[ghartshaw]

"James Kanze" <[email protected]> wrote in message

    [...]

The C++ standard explicitly says that one of the operands to []
must be a pointer, and the other must have an integral type.  No
array allowed.
I'd suggest that you read the standard.

I suggest you stop speaking such utter bool.

I'll repeat my suggestion.  Read the C++ standard.  And show me
where it defines an operator[] on an array.

    [...]
   int* array = new int[16];
   int* arr2 = new (array + 1) int[15];
That second line constructs a new array, of 15 elements, and
returns a pointer to the first element.  You cannot subtract
anything from arr2 until you've incremented.
 We're talking about a pointer in C++.  And in
C++, pointers have a type, and can only point to that type.

No they point to objects in memory.

And objects have a type.  Always.  And in C++, a pointer points
to a specific type, and cannot point to object of any other
type.  (There are a few special exceptions for char pointers.)

That's why pointer values are memory addresses.

At the hardware level.  But we're talking here about C++, and
not hardware pointers.

It's an arrangement of memory elements in one or more planes.

There are no planes in C++.  An array is a sequence of objects,
all of the same type.  (It's also an object in its own right.)

    [...]

 int* arr1 = new int[12];  /*Create an array of 12 int*/
 arr1[0] = 33;
 int* arr2 = new(++arr1) int[11]; /*Create an sub-array within original*/
You see.  You even say so: new int[11] creates a new array of 11
ints, and returns a pointer to the first element of that array.
Not a pointer to arr1.

No I said I created an array of 12 ints, then I create and
sub-array within it, which returns a pointer with a value
identical to that of arr1.

You didn't create a subarray.  You created a new array, using
some of the memory of the old one.  (C++ doesn't have
"subarrays", although I guess you could call an array which is a
subobject of some larger object a subarray.  That's not the case
here, however.)

 std::cout<< arr2[-1];   /*Access the original array using the sub-arrays
pointer*/
arr2 doesn't point into the first array; it points into the
array you created with the new expression which you used to
initialized arr2.

arr2 and arr1 both point to the same memory location.

So?  The same memory location can be used for different objects
at different times.

But the subobjects , which are in themselves  little complete
objects,  that extend beyond the overwritten memory survive
the overwrite operation.  So they were spared certain death by
the ending of their lifetime.

That's an interesting question, and I don't think that the C++
standard is clear about it.  In this case, however, the only
subobjects of an array are its elements.  Given your new
(++arr)int[11], if subobjects continue to exist, the first
element of arr is still valid.  But the others aren't.

I'm not too bothered about where definitions are in the standard,

But that's what defines C++.

I know its simply ridiculous to suggest you cannot index an
array in C++ and I don't intend wasting my time looking for
definitons to present to you for unreasonable responses.

I tend to agree that it's ridiculous that you cannot index into
an array---that in C++, the [] operator is only defined for
pointers, not for arrays.  But that's the way it is.  C++ has
inherited some fairly ridiculous characteristics from C.

Well it does index then if you have any clue what array indexing is.

But it doesn't if you understand C++.

This is what the C++ standard has to say about indexing.
As you can see there is no subscript operator defined for arrays
(only pointers) and that the only reason that an array an be used
as one of the operands in the array-to-pointer conversion defined
in 4.2.

From n3242:

4.2 Array-to-pointer conversion [conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown
bound of T" can be converted to a prvalue of type "pointer to T".
The result is a pointer to the first element of the array.

5.2.1 Subscripting [expr.sub]
1 A postfix expression followed by an expression in square brackets
is a postfix expression. One of the expressions shall have the
type "pointer to T" and the other shall have unscoped enumeration
or integral type. The result is an lvalue of type "T". The type
"T" shall be a completely-defined object type. The expression
E1[E2] is identical (by definition) to *((E1)+(E2)) [ Note: see
5.3 and 5.7 for details of * and + and 8.3.4 for details of
arrays -- end note ]

5.3.1 Unary operators [expr.unary.op]
1 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."

5.7 Additive operators [expr.add]
5 When an expression that has integral type is added or subtracted
from a pointer, the result has the type of the pointer operand.
If the pointer operand points to an element of an array object,
and the array is large enough, the result points to an element
offset from the original element such that the difference of the
subscripts of the resulting and original array elements equals
the integral expression.

8.3.4 Arrays [dcl.array]
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 ]

6 [ Note: Except where it has been declared for a class (13.5.5),
the subscript operator [] is interpreted in such a way that
E1[E2] is identical to *((E1)+(E2)). Because of the conversion
rules that apply to +, if E1 is an array and E2 an integer,
then E1[E2] refers to the E2-th member of E1. Therefore, despite
its asymmetric appearance, subscripting is a commutative
operation -- end note ]

 

[SG]

If it points to an element in the array then , by definition,
it points to the array.

What definition?

Stroustrup doesn't say... the pointer is to a single element and not a
pointer to the array.
All he says is it points to the initial element,

The initial element is a single element. The initial element is not an
array.

that doesn't mean it
doesn't also point to the array.

You think.

In fact quite the opposite it can't not
point to the array if it points to an element

Depends on the definitions.

int* p = new int[10];
p is a pointer to an array.

p *is* what it is *declared* to be, a pointer to int. In a context
where there is no room for misinterpretation, I'd say it is accetable
to use "p points to an array" as imprecise shortcut for "p points to
the initial element of an array". But in this context we are
discussing the precise terminology itself. At least I intend to stick
to the precise terminology.

If you disagree you are in the minority.

You are not the only one who does not understand arrays. I'm sure
there are many low quality (imprecise and/or wrong) array/pointer
tutorials out there. That's one reason to stick to quality books. You
know... the ones you did not read.

That was the subject for debate , not a statement of fact, as it was in the
*drumroll* subject field.

So, a statement as thread title is not a statement anymore.
Do you even listen to yourself?

What is this statement even supposed to mean? Try to be precise for
once. Try to make proper use of the C++ ISO standard's terminology.
Read §3 (basic concepts), §4 (standard conversions), §5 (expressions)..
If you havn't already downloaded a standard draft, look out for
N1804.pdf. It's an early C++0x draft with almost no C++0x feature in
it. Once you've read and understood these clauses, you will have the
following understanding:

int arr[8];
int* p = &arr[0];
int* q = arr;
int (&r)[8] = arr;

declared types:
----------------------------------------------
arr: int[8] "array of 8 int"
p, q: int* "pointer to int"
r: int(&)[8] "referene to array of 8 int"

expression type
----------------
arr int[8]
p int*
q int*
r int[8] (see §5/6)

Even though the type of the expression arr is int[8] we can use it to
initialize q because of §4.2 (array-to-poiter decay, a standard
conversion). This is not much different than

int integer = 3.1415;

Just because I can write this line of code does not make 3.1415 an
expression of type int. There is an implicit conversion in-between.
The array-to-pointer decay is such an implicit conersion and is even
considered during template argument deduction. You made use of that in
your code examples (possibly unknowingly). That's why I said that this
code of yours only shows how template argument deduction works in
combination with array expressions (expressions of array type like
'arr' and 'r') and pass-by-value. It does not show what the types of
these expressions are due to a possible implicit standard conversion.

Admittedly, array-to-pointer decay, the template argument deduction
rules, and the fact that function parameter *types* are *transformed*
from T[] and T[N] to be T* make it easy for newcomers to get the wrong
idea of what an array is. And you definitely got the wrong idea if you
start a thread with a title like "an array is just a pointer". Every
decent C++ programmer will disagree with you on that and say that you
don't understand the subtleties involved with arrays and pointers.

SG

 

[Paul]

For this particular case, Stroutstup was very clear in his
wording
with
his
series of examples in TCPPPL 5.3 Pointers into Arrays without
being
ambiguous,
or overly pedantic.

int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element

++p1; //pointer to 2nd element
++p1; //pointer to 3rd element
++p1; //pointer to 4th element
++p1; //pointer to no elements

p1 is a pointer to the array no matter what element it points to.

This statement is even less correct than others that you've made.

Why? becuase you say so?

This isn't about my beliefs or my opinions. I have authoritative
sources
that
state the case clearly in favor of my position and not yours.

Please reveal these secret authorative sources that you claim to have.

I've already revealed them in this very thread. You're just too busy
snipping
and "quickscanning" to use your own wording.

All you posted was the folowing:

<quote ref= "your authorative source">
int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element
</quote>

In what way do you interpret this to mean that p1 or p2 are not pointers
to
an array?
Because it is explicitly stated that p1 and p2 are pointers to a single
element.
A single element is in fact not the same as an array.
Had the author thought it pertinent to agree with your case, he would
have
by
now.

If it points to an element in the array then , by definition, it points
to
the array.

By which C++definition exactly? Because if you do not refer to a C++
definition
then we can add this statement to the long list of claims you have made
without
foundation.

He is specifying to where in the array it points , not that it doesn't
point
to the array.

In the array and to the array bear only subtle differences in English, but
in
C++ they are distinctly different. The addresses stored in the pointers
p1 and
p2 are addresses of singular integer objects. THAT is by definition.

So what does a pointer-to an array point to , if not one of its elements?

Well, that does not surprise me, I am one of several who have been
insulted
merely for providing you with the accurate reasons for your many faults.

The language chosen was deliberate. There are an infinite number of
incorrect
or imprecise things about pointers and arrays that Stroustrup does NOT
say. All
that matters is what he distinctly says is pertinent and correct. No more
and
no less.

We use similar abstactions in C++. STL containers for example. In
reality,
there are no "containers". These are predefined classes whose meaning can
be
expressed more easily using abstract ideas like "container." These
abstractions
are so widely used that they actually find their way into authoritative
texts,
but nevertheless they are abstractions. The abstractions themselves
however are
not the rule, they are the tool for describing and understanding.

Saying a pointer "points" is also an abstraction, but there is no actual
pointing going in in reality. The address that a pointer holds is the
address
to a distinct well-defined object, in the case of the TCPPPL 5.3 example
in this
thread, that object is of type int. The int itself is no more the array
itself
than the pointer points to an array itself.

What is a relevant Internet document? More specifically, what makes it
relevant? It is either an authoritative source or it is not.

What makes it relevant is that that it's:
a) written about C++
b) written by C++ programmers
c) about the subject
b) uses common C++ terminology

What makes you think it's not relevant?

Do you have a site in mind authored by somebody that has been published or
who
has served on the C++ committee that is congruent with your position?

Almost every C++ user in the world, except you and a few others in here,
use the same terminology as me .

You are delusional if you think you are in any form of majority with your
communication and language skills.

That is with:

int p = new int[10];

p is a pointer to an array. If you disagree you are in the minority .
thats
a fact.

More of your meaningless code when you fail to cite an authoritative
example
that supports your case for the even simpler example provided above. No
thanks,
I'll pass.

You'll pass? Well that's an admission of defeat IMO

Clearly you felt it was a statement of fact at the time you originally
posted.
More than once you have tried to prove it to be correct and have failed.

I haven't tried to prove anything to be correct. What I say *IS* correct,
the onus is on you to prove otherwise, which you seem incabable of doing.

 

[Paul]

"Leigh Johnston" <[email protected]> wrote in message


No the correct terminology is deduced.

From n3242:

4.2 Array-to-pointer conversion
[conv.array]
1 An lvalue or rvalue of type "array of N T" or "array of unknown bound of
T" can be
converted to a prvalue of type "pointer to T". The result is a pointer
to the first
element of the array.

What are you trying to say with that?

Are you :
a) Disagreeing with me and showing that you don't know the difference
between an array object and a template type arguement.?
And additionally showing that you don't know the correct terminology for
duduction of template arguments.

b) Showing it to prove to Leigh that he doesn't know the difference between
an array object and a template type arguement?

c) A learner and you are genuinely trying to find out what is the correct
terminology?

c) Neither of the above ?

 

[Paul]

[...]

The C++ standard explicitly says that one of the operands to []
must be a pointer, and the other must have an integral type. No
array allowed.
I'd suggest that you read the standard.

I suggest you stop speaking such utter bool.

I'll repeat my suggestion. Read the C++ standard. And show me
where it defines an operator[] on an array.

I'm not wasting my time arguing with you over something that is utterly and
ridiculously obvious.

An array can be indexed. Learn to live with it, its never gonna change.

[...]
int* array = new int[16];
int* arr2 = new (array + 1) int[15];
That second line constructs a new array, of 15 elements, and
returns a pointer to the first element. You cannot subtract
anything from arr2 until you've incremented.
We're talking about a pointer in C++. And in
C++, pointers have a type, and can only point to that type.

No they point to objects in memory.

And objects have a type. Always. And in C++, a pointer points
to a specific type, and cannot point to object of any other
type. (There are a few special exceptions for char pointers.)

That's why pointer values are memory addresses.

At the hardware level. But we're talking here about C++, and
not hardware pointers.

It's an arrangement of memory elements in one or more planes.

There are no planes in C++. An array is a sequence of objects,
all of the same type. (It's also an object in its own right.)

Yes there are planes in any concept of a matrix

[...]

int* arr1 = new int[12]; /*Create an array of 12 int*/
arr1[0] = 33;
int* arr2 = new(++arr1) int[11]; /*Create an sub-array within
original*/
You see. You even say so: new int[11] creates a new array of 11
ints, and returns a pointer to the first element of that array.
Not a pointer to arr1.

No I said I created an array of 12 ints, then I create and
sub-array within it, which returns a pointer with a value
identical to that of arr1.

You didn't create a subarray. You created a new array, using
some of the memory of the old one. (C++ doesn't have
"subarrays", although I guess you could call an array which is a
subobject of some larger object a subarray. That's not the case
here, however.)

So it's a sub array.

std::cout<< arr2[-1]; /*Access the original array using the
sub-arrays
pointer*/
arr2 doesn't point into the first array; it points into the
array you created with the new expression which you used to
initialized arr2.

arr2 and arr1 both point to the same memory location.

So? The same memory location can be used for different objects
at different times.

I know, I demonstrated doing just that with arr1 and arr2

But the subobjects , which are in themselves little complete
objects, that extend beyond the overwritten memory survive
the overwrite operation. So they were spared certain death by
the ending of their lifetime.

That's an interesting question, and I don't think that the C++
standard is clear about it. In this case, however, the only
subobjects of an array are its elements. Given your new
(++arr)int[11], if subobjects continue to exist, the first
element of arr is still valid. But the others aren't.

Well the memory is still allocated , so unless random memory writes are
allowed , nothing can take that memory untill I delete the larger of the two
arrays.

But that's what defines C++.

You are being ridicoulous here, the standard is clear about how an array is
implicitly converted to a pointer when subscripted and (*((p)+(i))) etc ,
etc, and all the rest of it we've been over a hundred times before.

I know its simply ridiculous to suggest you cannot index an
array in C++ and I don't intend wasting my time looking for
definitons to present to you for unreasonable responses.

I tend to agree that it's ridiculous that you cannot index into
an array---that in C++, the [] operator is only defined for
pointers, not for arrays. But that's the way it is. C++ has
inherited some fairly ridiculous characteristics from C.

Its not, the C++ standard clearly states that with E1[E2] ,***** if E1 is an
array. ******

This does not mean we *cannot* subscript arrays, it means the opposite ffs.

But it doesn't if you understand C++.

Don't speak nonsense

Thank god for reality, or I'd be beginning to think I was the only sane
person on the planet.

 

[Paul]

6 [ Note: Except where it has been declared for a class (13.5.5),

the subscript operator [] is interpreted in such a way that
E1[E2] is identical to *((E1)+(E2)). Because of the conversion
rules that apply to +,

ALERT! ALERT! ALERT! ALERT!
******************************
if E1 is an array and E2 an integer,

*****************************
ALERT! ALERT! ALERT! ALERT!

then E1[E2] refers to the E2-th member of E1. Therefore, despite
its asymmetric appearance, subscripting is a commutative
operation -- end note ]

omfg what next?

 

[Paul]

If it points to an element in the array then , by definition,
it points to the array.

What definition?

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The definition of common sense and logic.

Not getting into a big debate with you because text not indenting and im too
tired.

Stroustrup doesn't say... the pointer is to a single element and not a
pointer to the array.
All he says is it points to the initial element,

The initial element is a single element. The initial element is not an
array.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

THe initial element is both an element and the array

that doesn't mean it
doesn't also point to the array.

You think.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I know, its cannot point to an element in the array without also pointing to
the array.

In fact quite the opposite it can't not
point to the array if it points to an element

Depends on the definitions.

int* p = new int[10];
p is a pointer to an array.

p *is* what it is *declared* to be, a pointer to int. In a context
where there is no room for misinterpretation, I'd say it is accetable
to use "p points to an array" as imprecise shortcut for "p points to
the initial element of an array". But in this context we are
discussing the precise terminology itself. At least I intend to stick
to the precise terminology.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Unless the allocation failed:

p CANNOT POSSIBLY NOT POINT TO AN ARRAY.

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

If you disagree you are in the minority.

You are not the only one who does not understand arrays. I'm sure
there are many low quality (imprecise and/or wrong) array/pointer
tutorials out there. That's one reason to stick to quality books. You
know... the ones you did not read.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
LOL see above , Im tired now , goodnight or should I say good morning.

Oh i see ther eis still alot to read, I'll finish it tomorrow or today.

That was the subject for debate , not a statement of fact, as it was in
the
*drumroll* subject field.

So, a statement as thread title is not a statement anymore.
Do you even listen to yourself?

What is this statement even supposed to mean? Try to be precise for
once. Try to make proper use of the C++ ISO standard's terminology.
Read §3 (basic concepts), §4 (standard conversions), §5 (expressions).
If you havn't already downloaded a standard draft, look out for
N1804.pdf. It's an early C++0x draft with almost no C++0x feature in
it. Once you've read and understood these clauses, you will have the
following understanding:

int arr[8];
int* p = &arr[0];
int* q = arr;
int (&r)[8] = arr;

declared types:
----------------------------------------------
arr: int[8] "array of 8 int"
p, q: int* "pointer to int"
r: int(&)[8] "referene to array of 8 int"

expression type
----------------
arr int[8]
p int*
q int*
r int[8] (see §5/6)

Even though the type of the expression arr is int[8] we can use it to
initialize q because of §4.2 (array-to-poiter decay, a standard
conversion). This is not much different than

int integer = 3.1415;

Just because I can write this line of code does not make 3.1415 an
expression of type int. There is an implicit conversion in-between.
The array-to-pointer decay is such an implicit conersion and is even
considered during template argument deduction. You made use of that in
your code examples (possibly unknowingly). That's why I said that this
code of yours only shows how template argument deduction works in
combination with array expressions (expressions of array type like
'arr' and 'r') and pass-by-value. It does not show what the types of
these expressions are due to a possible implicit standard conversion.

Admittedly, array-to-pointer decay, the template argument deduction
rules, and the fact that function parameter *types* are *transformed*
from T[] and T[N] to be T* make it easy for newcomers to get the wrong
idea of what an array is. And you definitely got the wrong idea if you
start a thread with a title like "an array is just a pointer". Every
decent C++ programmer will disagree with you on that and say that you
don't understand the subtleties involved with arrays and pointers.

SG

 

[hanukas]

On 21/03/2011 13:57, Paul wrote:

On 21/03/2011 11:58, Paul wrote:
[...]
Consider:
int* x = new int[10];
[...]
However, no one competent would confuse this for "x has array type",
"x is an array", nor "x has type pointer to array".
Yes but the whole thread is named "array is pointer". That is Paul's
thesis. Rest of it is terribly dim and lacks any logic in most places.
Of course. In my earlier post, I clearly stated that Paul is not right
on 95%+ of the points which he tries to make, and is frequently not
even wrong due to his unique use of the English language. Still, I was
slightly irritated that no one was willing to give him that for the
code:
int* x = new int[10];
"x points to an array". I know I could easily find myself saying
exactly that.
============================================================
Owned!
"x points to an array" is different to "x is a pointer to an array";
the first form is ambiguous but probably OK in informal settings; the
second form is an incorrect description of what "x" is.
Nonsense if x is a pointerto an array then , by defintion, x points to
an array.
*shrug*

Correct but that is not what I said.  Your comprehension of the English
language and logic is very poor.

Nothing wrong with my English.
You were trying to say : "x points to an array"  is OK but "x is a pointer
to the array" is completely wrong. You are speaking complete nonsense
because if one is true the other, by definition, is also true.

You're confusing value and type. The type of x is "pointer to int",
the value of the pointer to int is address of array element.

The x points to array, yes, yes. But the type is pointer to int, get
it? I have my doubts.. ;---o

Value doesn't change type. That's what you got wrong all this time.
Have a nice one.

 

[Peter Remmers]

Am 22.03.2011 00:33, schrieb Paul:

I'm an immature 57 year old.

OMG. I knew the first part, but I'm shocked at the second part.

 

[SG]

[...]

You are being ridicoulous here, the standard is clear about how an array
is implicitly converted to a pointer when subscripted and (*((p)+(i)))
etc, etc, [...]

FYI: There is a difference between "X is Y" and "X is convertible to
Y".

If an array _was_ "just a pointer" (the subject line you've chosen)
there would be no need for such a _conversion_, would there?

Anyhow, you should take your time to read and comprehend what I posted
earlier. In fact, you should make it a habit to think about what
people write some more before you hit the reply button.

SG

 

[SG]

On 21/03/2011 23:57, Paul wrote: [...]

No the correct terminology is deduced.

No the correct terminology is "array-to-pointer conversion".

Well, template argument deduction deduces T (in this case) to be a
pointer type due to the rules in §14.8.2.1/1-2:

"Template argument deduction is done by comparing each function
template parameter type (call it P) with the type of the
corresponding argument of the call (call it A).

If P is not a reference type:
- If A is an array type, the pointer type produced by array-to-
pointer standard conversion (4.2) is used in place of A for
type deduction
[...]"

And after template argument deduction, the argument 'a' of array type
A is converted to a pointer value. So, neither of you is wrong in this
regard.

But Paul is wrong to assume that T (and thus P) being deduced to be a
pointer type implies that A is a pointer type. This is obviously not
the case, as can be seen in the C++ ISO standard quote I provided
above.

Let's see how Paul is going to try to weasel himself out of this one.

SG

 

[Paul]

For this particular case, Stroutstup was very clear in his
wording
with
his
series of examples in TCPPPL 5.3 Pointers into Arrays without
being
ambiguous,
or overly pedantic.

int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element

++p1; //pointer to 2nd element
++p1; //pointer to 3rd element
++p1; //pointer to 4th element
++p1; //pointer to no elements

p1 is a pointer to the array no matter what element it points
to.

This statement is even less correct than others that you've
made.

Why? becuase you say so?

This isn't about my beliefs or my opinions. I have authoritative
sources
that
state the case clearly in favor of my position and not yours.

Please reveal these secret authorative sources that you claim to
have.

I've already revealed them in this very thread. You're just too
busy
snipping
and "quickscanning" to use your own wording.

All you posted was the folowing:

<quote ref= "your authorative source">
int v[] = {1,2,3,4};
int* p1 =v; //pointer to initial element (implicit conversion)
int* p2 =&v[0]; //pointer to initial element
</quote>

In what way do you interpret this to mean that p1 or p2 are not
pointers
to
an array?
Because it is explicitly stated that p1 and p2 are pointers to a
single
element.
A single element is in fact not the same as an array.
Had the author thought it pertinent to agree with your case, he would
have
by
now.

If it points to an element in the array then , by definition, it points
to
the array.

By which C++definition exactly?

Hello? No answer? Should we assume that you do not have a C++ definition
then?
Surely if you know that you are correct like you say you do, then it would
be
easy to cite the definition that supports you, right? Oh wait, I forgot,
it
isn't your burden to stand by your words. It's everybody elses.

By the definition .. it points to an array.

What definition do you think stupid.?

How about correctly answering the question I asked above before asking
some of
your own that do not even address the example at hand.

OK I answered now you answer me.
What does a pointer-to an array point to , if not one of its elements?

I think I am actually starting to feel sorry for you here. Your list is
replete
with failure.

Don't is misguided.
I detest arseholes like you and if I seen you face to face I think I would
need to be restrained form punching you in your cheeky little mouth.
I am 6' 4" and built like a tank. I don't think you would be feeling sorry
me , you would be feeling very scared.

<snip>

 

[Paul]

It is a 2dim array. How can this not be a pointer to a dynamic array?

int (*pa)[42] = new int[42][42];


Come on?. Tell me how , even in the densest of pea-like brains like
yours, this cannot be a pointer to an array?

You fail yet again. I never said "pa" was not a pointer to an array; of
course it is a pointer to an array; it is a pointer to a 1d array of type
int[42].

It's a pointer to a 2d array
According to you any dynamic array is, not unlike you, 1 dimension short of
a picnic.


READ THE C++ STANDARDS.
"A consistent rule is followed for multidimensional arrays. If E is an
ndimensional
array of rank
i´ j´ . . . ´k, then E appearing in an expression is converted to a pointer
to an (n - 1 )dimensional
array
with rank j´ . . . ´k. If the * operator, either explicitly or implicitly as
a result of subscripting, is applied to
this pointer, the result is the pointedto
(n - 1 )dimensional
array, which itself is immediately converted
into a pointer."

No the correct terminology is "array-to-pointer conversion".

No it's not the array doesn't change at all, its not converted to anything.
The correct terminology is template deduction.

 

[Paul]

On 21/03/2011 23:57, Paul wrote: [...]

No the correct terminology is deduced.

No the correct terminology is "array-to-pointer conversion".

--Well, template argument deduction deduces T (in this case) to be a
--pointer type due to the rules in §14.8.2.1/1-2:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

It changes the type it doens't convert any array. It's called template
deduction.

The rest of your post looks like, knowing you, utter twisted garbage and
bollocks for lack of a better term.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx




"Template argument deduction is done by comparing each function
template parameter type (call it P) with the type of the
corresponding argument of the call (call it A).

If P is not a reference type:
- If A is an array type, the pointer type produced by array-to-
pointer standard conversion (4.2) is used in place of A for
type deduction
[...]"

And after template argument deduction, the argument 'a' of array type
A is converted to a pointer value. So, neither of you is wrong in this
regard.

But Paul is wrong to assume that T (and thus P) being deduced to be a
pointer type implies that A is a pointer type. This is obviously not
the case, as can be seen in the C++ ISO standard quote I provided
above.

Let's see how Paul is going to try to weasel himself out of this one.

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

I don't need to "weasel out" of anything , your the weasel around here.