An array is just a pointer
Paul
I have this array:
int (*array)[4] = new int[4][4];
++array;
array[-1][3] = 4;
Is this an array? Or is it not an array?
Also I have another array:
int* arr1 = new int[12];
arr1[0] = 33;
int* arr2 = new(++arr1) int[11];
std::cout<< arr2[-1];
Is this an array or is it just a pointer?
Or as Noah says its a pointer that doesn't even point to an array. Surely
this is pushing the limits of plain idiocy. :-)
Leigh Johnston
> Hi
> I have this array:
>
> int (*array)[4] = new int[4][4];
> ++array;
> array[-1][3] = 4;
>
> Is this an array? Or is it not an array?
It is not an array; it is a pointer to an array.
>
> Also I have another array:
>
> int* arr1 = new int[12];
> arr1[0] = 33;
> int* arr2 = new(++arr1) int[11];
> std::cout<< arr2[-1];
>
>
> Is this an array or is it just a pointer?
arr1 and arr2 are both pointers not arrays.
/Leigh
Juha Nieminen
> On 17/03/2011 20:28, Paul wrote:
>> Hi
>> I have this array:
>>
>> int (*array)[4] = new int[4][4];
>> ++array;
>> array[-1][3] = 4;
>>
>> Is this an array? Or is it not an array?
>
> It is not an array; it is a pointer to an array.
In fact, it's just a pointer to some memory location. The language
makes no difference whether that memory location contains one object
or several objects at contiguous memory locations. (Well, with one
single exception: delete[] makes the distinction and is able to resolve
how many objects there are. But other than this there is no way to
distinguish whether the pointer is pointing to a single object, to an
array, or even to an invalid memory location.)
You can jump forwards and backwards with the pointer (either by using
the indexing syntax or operator+, it doesn't really make much of a
difference in terms of functionality, only in terms of syntax), but
there is no guarantee that it will work correctly, if the pointer ends
up pointing to an invalid location.
This behavior comes from C, to which in turn it comes from machine code:
In most CPU architectures (especially the ones C was designed for) the
CPU doesn't make any distinction between memory addresses pointing to
single objects or arrays either. It's up to the code to do things
correctly; the CPU won't do any checks (except for segment violations,
if the architecture's memory model supports that).
Leigh Johnston
> Leigh Johnston<le...@i42.co.uk> wrote:
>> On 17/03/2011 20:28, Paul wrote:
>>> Hi
>>> I have this array:
>>>
>>> int (*array)[4] = new int[4][4];
>>> ++array;
>>> array[-1][3] = 4;
>>>
>>> Is this an array? Or is it not an array?
>>
>> It is not an array; it is a pointer to an array.
>
> In fact, it's just a pointer to some memory location. The language
> makes no difference whether that memory location contains one object
> or several objects at contiguous memory locations. (Well, with one
Not quite true: the type of "array" is "int (*)[4]" not "int *" so it is
both a pointer and a pointer to an array just as "int *" is both a
pointer and a pointer to a scalar.
/Leigh
Peter Remmers
> Hi
> I have this array:
>
> int (*array)[4] = new int[4][4];
array is a pointer to an array of 4 ints.
That means what it points to is not just one integer but 4 integers.
That means that if you do
> ++array;
it then points to an address that is 4*sizeof(int) higher, not just
1*sizeof(int).
> array[-1][3] = 4;
Assuming these 4*4 ints are contiguous im memory, without padding, then
that assignment writes a 4 to the top-right corner of the matrix.
> Is this an array? Or is it not an array?
There is an unnamed array of 4*4 integers on the heap. And all you have
is a pointer named "array" of type "int (*)[4]" to the first 4 integers.
> Also I have another array:
>
> int* arr1 = new int[12];
> arr1[0] = 33;
> int* arr2 = new(++arr1) int[11];
This is actually only harmless because these are integers. It's (in this
case) equivalent to
int *arr2 = ++arr1;
However, if the elements were of some complex datatype, something that
has a constructor and destructor, it would be UB I guess, because you
construct new instances at memory locations where other instances
already live, without destroying those first.
> std::cout<< arr2[-1];
Well, as arr2 is just a pointer you can offset it by any number you
want, provided you don't end up accessing memory you shouldn't touch. It
works in this case because it points to the second element in the array.
int arr3[12];
std::cout<< arr3[-1];
As arr3 can be implicitly converted to a pointer, you can offset it by
any number you want, but the difference is that in this case it is
pretty certain that you're accessing a memory location you shouldn't be
touching.
> Is this an array or is it just a pointer?
> Or as Noah says its a pointer that doesn't even point to an array. Surely
> this is pushing the limits of plain idiocy. :-)
>
>
Peter
Juha Nieminen
> Not quite true: the type of "array" is "int (*)[4]" not "int *" so it is
> both a pointer and a pointer to an array just as "int *" is both a
> pointer and a pointer to a scalar.
Technically speaking only in the sense of how indexing the pointer
changes its value (iow. how big of a jump it takes when you add 1 to it).
Paul
"Leigh Johnston" <le...@i42.co.uk> wrote in message
news:IaudnROsWrRG6x_Q...@giganews.com...
> On 17/03/2011 20:51, Juha Nieminen wrote:
>> Leigh Johnston<le...@i42.co.uk> wrote:
>>> On 17/03/2011 20:28, Paul wrote:
>>>> Hi
>>>> I have this array:
>>>>
>>>> int (*array)[4] = new int[4][4];
>>>> ++array;
>>>> array[-1][3] = 4;
>>>>
>>>> Is this an array? Or is it not an array?
>>>
>>> It is not an array; it is a pointer to an array.
>>
>> In fact, it's just a pointer to some memory location. The language
>> makes no difference whether that memory location contains one object
>> or several objects at contiguous memory locations. (Well, with one
>
the newexpression
yields a pointer to the initial element of the array.
This means that
int* x = new int[12];
Yields a pointer to an array. Not to *any* memory location.
> Not quite true: the type of "array" is "int (*)[4]" not "int *" so it is
> both a pointer and a pointer to an array just as "int *" is both a pointer
> and a pointer to a scalar.
>
Leigh seems to think that int* cannot be a pointer to an array but that is
in direct conflict with the C++ standards.
Also note how stupid his argument is with the following code:
void foo(int p[]){
std::cout<< p << typeid(p).name();
}
int main()
{
int arr[];
foo("Is this an array?" );
}
Is an array passed to foo, has an array been processed by cout? Of course it
has. See the C++ standards to confirm the definition of string literals and
character arrays.
It's quite apparent some people around here cannot understand the very
basics about C++ arrays. :-)
Noah Roberts
> Leigh Johnston<le...@i42.co.uk> wrote:
>> On 17/03/2011 20:28, Paul wrote:
>>> Hi
>>> I have this array:
>>>
>>> int (*array)[4] = new int[4][4];
>>> ++array;
>>> array[-1][3] = 4;
>>>
>>> Is this an array? Or is it not an array?
>>
>> It is not an array; it is a pointer to an array.
>
> In fact, it's just a pointer to some memory location. The language
> makes no difference whether that memory location contains one object
> or several objects at contiguous memory locations. (Well, with one
> single exception: delete[] makes the distinction and is able to resolve
> how many objects there are. But other than this there is no way to
> distinguish whether the pointer is pointing to a single object, to an
> array, or even to an invalid memory location.)
That exception is even more of an exception than that. The pointer
passed to delete[] had darn well better be the same one returned by
new[]. The little ++array thing in the example code had better be
undone or delete[] is going to totally freak out.
The delete[] operator in fact doesn't actually know if the pointer
points at an array or not any better than we can discover, it just
assumes so and tries to fetch some implementation defined information
using the supplied address as a key. If that address isn't in the
'database' then delete[] is going to misbehave.
Leigh Johnston
>
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:IaudnROsWrRG6x_Q...@giganews.com...
>> On 17/03/2011 20:51, Juha Nieminen wrote:
>>> Leigh Johnston<le...@i42.co.uk> wrote:
>>>> On 17/03/2011 20:28, Paul wrote:
>>>>> Hi
>>>>> I have this array:
>>>>>
>>>>> int (*array)[4] = new int[4][4];
>>>>> ++array;
>>>>> array[-1][3] = 4;
>>>>>
>>>>> Is this an array? Or is it not an array?
>>>>
>>>> It is not an array; it is a pointer to an array.
>>>
>>> In fact, it's just a pointer to some memory location. The language
>>> makes no difference whether that memory location contains one object
>>> or several objects at contiguous memory locations. (Well, with one
>>
> No it's not the standards states that when the typeid denotes an array
> type, the newexpression
> yields a pointer to the initial element of the array.
>
> This means that
> int* x = new int[12];
>
> Yields a pointer to an array. Not to *any* memory location.
x is a pointer to a scalar not a pointer to an array; the scalar just
happens to be the first element of an array.
>
>
>> Not quite true: the type of "array" is "int (*)[4]" not "int *" so it
>> is both a pointer and a pointer to an array just as "int *" is both a
>> pointer and a pointer to a scalar.
>>
> Leigh seems to think that int* cannot be a pointer to an array but that
> is in direct conflict with the C++ standards.
I see no conflict with the C++ standard; int* is a pointer to an int
scalar not a pointer to an array.
>
> Also note how stupid his argument is with the following code:
>
> void foo(int p[]){
> std::cout<< p << typeid(p).name();
> }
>
> int main()
> {
> int arr[];
> foo("Is this an array?" );
> }
>
>
> Is an array passed to foo, has an array been processed by cout? Of
> course it has. See the C++ standards to confirm the definition of string
> literals and character arrays.
WTF are you talking about? Your code is nonsense (it won't compile).
The type of a string literal is an array; nobody said otherwise.
> It's quite apparent some people around here cannot understand the very
> basics about C++ arrays. :-)
It is quite apparent to everyone who is lacking a clue here.
/Leigh
Paul
"Peter Remmers" <p.re...@expires-2011-03-31.arcornews.de> wrote in message
news:4d827ef5$0$6766$9b4e...@newsspool3.arcor-online.net...
if it is an array or if its not. Let me explain further:
void foo(char p[]){std::cout<< p;}
foo("Is this an array?");
Is an array passed to the function or not? Is an array processed by cout or
not?
An array is a pointer in most situations and it's complete nonsense to
suggest its not an array because its a pointer. That's my opinion, I don't
know yours because you didn't make your opinion too clear.
As for Leigh and co's opinion about arrays not being arrays because they are
pointers, well that's obviously complete nonsense, I hope you don't share
their opinion :-S
Paul
> On 17/03/2011 21:45, Paul wrote:
>>
>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
>> news:IaudnROsWrRG6x_Q...@giganews.com...
>>> On 17/03/2011 20:51, Juha Nieminen wrote:
>>>> Leigh Johnston<le...@i42.co.uk> wrote:
>>>>> On 17/03/2011 20:28, Paul wrote:
>>>>>> Hi
>>>>>> I have this array:
>>>>>>
>>>>>> int (*array)[4] = new int[4][4];
>>>>>> ++array;
>>>>>> array[-1][3] = 4;
>>>>>>
>>>>>> Is this an array? Or is it not an array?
>>>>>
>>>>> It is not an array; it is a pointer to an array.
>>>>
>>>> In fact, it's just a pointer to some memory location. The language
>>>> makes no difference whether that memory location contains one object
>>>> or several objects at contiguous memory locations. (Well, with one
>>>
>> No it's not the standards states that when the typeid denotes an array
>> type, the newexpression
>> yields a pointer to the initial element of the array.
>>
>> This means that
>> int* x = new int[12];
>>
>> Yields a pointer to an array. Not to *any* memory location.
>
> x is a pointer to a scalar not a pointer to an array; the scalar just
> happens to be the first element of an array.
>
"the newexpression yields a pointer to the initial element (if any) of the
array."
>>
>>
>>> Not quite true: the type of "array" is "int (*)[4]" not "int *" so it
>>> is both a pointer and a pointer to an array just as "int *" is both a
>>> pointer and a pointer to a scalar.
>>>
>> Leigh seems to think that int* cannot be a pointer to an array but that
>> is in direct conflict with the C++ standards.
>
> I see no conflict with the C++ standard; int* is a pointer to an int
> scalar not a pointer to an array.
>
See above.
>> Also note how stupid his argument is with the following code:
>>
>> void foo(int p[]){
>> std::cout<< p << typeid(p).name();
>> }
>>
>> int main()
>> {
>> int arr[];
>> foo("Is this an array?" );
>> }
>>
>>
>> Is an array passed to foo, has an array been processed by cout? Of
>> course it has. See the C++ standards to confirm the definition of string
>> literals and character arrays.
>
> WTF are you talking about? Your code is nonsense (it won't compile). The
> type of a string literal is an array; nobody said otherwise.
>
Obviously the function parameter should be char p[]. SO I don't proof read
posting to zonks like you.
>> It's quite apparent some people around here cannot understand the very
>> basics about C++ arrays. :-)
>
> It is quite apparent to everyone who is lacking a clue here.
>
Yes you. :)
Leigh Johnston
It is quite simple: there is a difference between "pointer to an array"
and "pointer to the first element of an array"; you need to engage your
brain.
/Leigh
Leigh Johnston
Maybe the following will help you understand the semantic differences
involved:
int main()
{
int* p1 = new int[42]; // 'p1' is a pointer to the first element of an
array
int (*p2)[42] = new int[1][42]; // 'p2' is a pointer to an array
}
/Leigh
Paul
thing as "a pointer to an array".
Leigh Johnston
You are failing to understand the semantic differences involved.
/Leigh
Paul
following :
"the newexpression yields a pointer to the initial element (if any) of the
array. [Note: both new int and new int[10] have type int* and the type of
new int[i][10] is
int (*)[10]. ]"
The standards define both of these types to be pointers to the array, they
are just different *types* of pointer.
Leigh Johnston
No; for the final time: int* is not a pointer to an array; int* is a
pointer to a scalar; the Standard clearly states "the new-expression
yields a pointer to the initial element (if any) of the array"; it
doesn't state that "the new-expression yields a pointer to the array".
You have repeatedly shown that you are unable to get firm grasp on
technical matters and I am not sure how you can be helped; you can start
be realizing that if *everybody* is disagreeing with you then *you* are
probably wrong.
/Leigh
Peter Remmers
> You don't seem to be clear, maybe you don't like committing yourself to say
> if it is an array or if its not. Let me explain further:
>
> void foo(char p[]){std::cout<< p;}
>
> foo("Is this an array?");
This gives a warning, as the type of the string literal is "const
char[18]", and it only converts to "char*" for compatibility with C.
foo's parameter is lacking the const.
> Is an array passed to the function or not? Is an array processed by cout or
> not?
You pass a string literal, which is indeed an unnamed char array, but
what foo receives is a "char*", and I'm pretty sure cout's
"operator<<(char*)" overload is called, which means it also receives a
char pointer.
As far as I know (haven't noticed any difference to date), these two are
completely equivalent, and differ only in syntax:
void foo(char p[]) { ... }
void foo(char *p) { ... }
If I print sizeof(p) in foo, I get "4" in both variants on my machine.
Even if you do this:
void foo(char p[18]) { ... }
you still get "4" for sizeof(p).
Only something like this will give "18":
void foo(char (&p)[18]) { .. }
> An array is a pointer in most situations and it's complete nonsense to
> suggest its not an array because its a pointer. That's my opinion, I don't
> know yours because you didn't make your opinion too clear.
An array can be converted to a pointer, and once the conversion is done,
the information about the number of elements is lost.
If you pass such a pointer to some function, the receiving side will
only see a pointer to one element and can only speculate as to how many
elements, if any, follow (or even precede!) the element that it points
to. That's why, for functions that are to operate on an array of
elements, usually the length must be passed in a separate parameter. For
functions that receive char*, the assumption is usually that it is a
zero-terminated string, and so a length is not necessary.
The story is a bit different for templates. An example is the _countof
macro I mentioned elsewhere.
> As for Leigh and co's opinion about arrays not being arrays because they are
> pointers, well that's obviously complete nonsense, I hope you don't share
> their opinion :-S
An array is an array, and a pointer is a pointer. Maybe you think
"identifies an array" is the same as "points to an array"?
There you go, now you now my position (as if it wasn't clear before). Go
ahead and look down on me, like you do with everyone who does not share
your weird beliefs. I will bear it like a man.
Peter
Paul
Err no your nonsense is becoming beyond belief .
A pointer to the first element *IS* a pointer to the array.
The standards states clearly that both int* and int(*)[10] are pointers to
the first element. There is no difference in what these pointers point to.
You must think int(*)[10] is an array of pointers or something , *shakes
head* no I don't know what nonsense you think.
Leigh Johnston
Yes everything seems like nonsense to you as you are either unable or
unwilling to be get a firm technical grasp on C++ matters.
/Leigh
James Kanze
> I have this array:
> int (*array)[4] = new int[4][4];
> ++array;
> array[-1][3] = 4;
> Is this an array? Or is it not an array?
Is what an array or not? What you allocated is an array. The
variable "array" is a pointer, not an array (as sizeof(array)
will clearly show).
> Also I have another array:
> int* arr1 = new int[12];
> arr1[0] = 33;
> int* arr2 = new(++arr1) int[11];
> std::cout<< arr2[-1];
I'm not sure, but I think that last line has undefined behavior.
The array new operator returns a pointer to the *first* element
of an array.
> Is this an array or is it just a pointer?
Again, is what an array or just a pointer. All of the named
variables in your code are pointers, not arrays.
> Or as Noah says its a pointer that doesn't even point to an
> array. Surely this is pushing the limits of plain idiocy. :-)
An int* is a pointer. It may point to the first element of an
array (or anywhere inside an array, for that matter), but it is
and remains a pointer to a single int.
--
James Kanze
James Kanze
> Leigh Johnston <le...@i42.co.uk> wrote:
[...]
> This behavior [using pointer arithmetic] comes from C, to
> which in turn it comes from machine code:
C gets it from B, which was an interpreted language. Machine
code has nothing to do with it. B gets it because B is untyped:
everything was a machine word (and there were different operators
in the language for floating point arithmetic and integral
arithmetic). Of course, an array doesn't fit very well into a
machine word, so when you declared an array, the compiler created
an anonymous array, and a word which was initialized with the
address of the first element of the array. All the programmer
could access, of course, was this word.
--
James Kanze
James Kanze
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:IaudnROsWrRG6x_Q...@giganews.com...
> > On 17/03/2011 20:51, Juha Nieminen wrote:
> >> Leigh Johnston<le...@i42.co.uk> wrote:
> >>> On 17/03/2011 20:28, Paul wrote:
> >>>> Hi
> >>>> I have this array:
> >>>> int (*array)[4] = new int[4][4];
> >>>> ++array;
> >>>> array[-1][3] = 4;
> >>>> Is this an array? Or is it not an array?
> >>> It is not an array; it is a pointer to an array.
> >> In fact, it's just a pointer to some memory location. The
> >> language makes no difference whether that memory location
> >> contains one object or several objects at contiguous memory
> >> locations. (Well, with one
> No it's not the standards states that when the typeid denotes
> an array type, the newexpression yields a pointer to the
> initial element of the array.
> This means that
> int* x = new int[12];
> Yields a pointer to an array.
You just contradicted your previous statement. An array new
expression yields a pointer to the first element of the allocated
array, not a pointer to the array. Pointer arithmetic and how
arrays are laid out in memory allow us to use that pointer to
access other elements of the array.
[...]
> void foo(int p[]){
> std::cout<< p << typeid(p).name();
> }
> int main()
> {
> int arr[];
> foo("Is this an array?" );
> }
> Is an array passed to foo,
It can't be. The standard explicitly says that arrays can't be
passed as arguments.
> has an array been processed by cout? Of course it
> has.
No. There's a special rule that says that arrays can't be passed
to functions. (Pointers to arrays, and references to arrays,
yes, but not arrays.)
> See the C++ standards to confirm the definition of string literals and
> character arrays.
But you can't pass a string literal or a character array to a
function.
> It's quite apparent some people around here cannot understand the very
> basics about C++ arrays. :-)
And it's quite apparent that you are one of them.
--
James Kanze
Paul
terminated string.
You still seem a bit unclear whether or not the array is received by
function, you state the function receives a char*(not an array). The way you
said it seemed to imply what I put in brackets.
Am I correct in assuming you think the array I passed is not an array
(inside the function) because i passed a pointer to it?
You think the array is not an array anymore for some reason?
>> An array is a pointer in most situations and it's complete nonsense to
>> suggest its not an array because its a pointer. That's my opinion, I
>> don't
>> know yours because you didn't make your opinion too clear.
> An array can be converted to a pointer, and once the conversion is done,
> the information about the number of elements is lost.
> If you pass such a pointer to some function, the receiving side will only
> see a pointer to one element and can only speculate as to how many
> elements, if any, follow (or even precede!) the element that it points to.
> That's why, for functions that are to operate on an array of elements,
> usually the length must be passed in a separate parameter. For functions
> that receive char*, the assumption is usually that it is a zero-terminated
> string, and so a length is not necessary.
>
> The story is a bit different for templates. An example is the _countof
> macro I mentioned elsewhere.
>
>> As for Leigh and co's opinion about arrays not being arrays because they
>> are
>> pointers, well that's obviously complete nonsense, I hope you don't share
>> their opinion :-S
>
> An array is an array, and a pointer is a pointer. Maybe you think
> "identifies an array" is the same as "points to an array"?
>
> There you go, now you now my position (as if it wasn't clear before). Go
> ahead and look down on me, like you do with everyone who does not share
> your weird beliefs. I will bear it like a man.
>
Well not really you still didn't really make yourself clear. You said an
array was passed but the function received a pointer.
Its generally known as pass by reference. And you pass a pointer to the
array, if I dereference that pointer I access the arrays data for example:
void voo(char* p){
char c = p[0];
}
Do you agree that I'm indexing the array here, or do you somehow think there
is no array?
Paul
> On 17/03/2011 23:00, Paul wrote:
>>
James Kanze
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:vfadnXg83rtyHh_Q...@giganews.com...
> > On 17/03/2011 21:45, Paul wrote:
[...]
> >> This means that
> >> int* x = new int[12];
> >> Yields a pointer to an array. Not to *any* memory location.
> > x is a pointer to a scalar not a pointer to an array; the scalar just
> > happens to be the first element of an array.
> You are wrong to say that its not a pointer to the array ref C++ standards:
> "the newexpression yields a pointer to the initial element (if any) of the
> array."
Reread that, please. The new expression yields a pointer to the
initial element. Not to the array, but to just one element of
the array.
[...]
> Obviously the function parameter should be char p[].
When the top level type of a function parameter is an array, it
is converted to a pointer. You cannot declare a function which
has a parameter of array type. In other words:
void f(char p[]);
and
void f(char*p);
declare exactly the same function.
In one of your examples, you used `cout << typeid(p).name()'.
Try it on a local variable with an array type, on a local
variable with pointer type, and on a function parameter declared
as an array.
--
James Kanze
James Kanze
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
[...]
> Err no "a pointer to the first element of an array" means exactly the same
> thing as "a pointer to an array".
Since when? Since when is the first element of an array the same
thing as the array?
--
James Kanze
Paul
"James Kanze" <james...@gmail.com> wrote in message
news:1a3230b7-ce7c-4e38...@fe9g2000vbb.googlegroups.com...
In what way have i condracted anything?
> [...]
>> void foo(int p[]){
>> std::cout<< p << typeid(p).name();
>> }
>
>> int main()
>> {
>> int arr[];
>> foo("Is this an array?" );
>> }
>
>> Is an array passed to foo,
>
> It can't be. The standard explicitly says that arrays can't be
> passed as arguments.
>
Where? Can you show me the quote.
You are obviously speaking utter nonsense. I can pass a array by reference.
>> has an array been processed by cout? Of course it
>> has.
>
> No. There's a special rule that says that arrays can't be passed
> to functions. (Pointers to arrays, and references to arrays,
> yes, but not arrays.)
SO you can pass a pointer to an array, that is called passing by reference.
>
>> See the C++ standards to confirm the definition of string literals and
>> character arrays.
>
> But you can't pass a string literal or a character array to a
> function.
I just did .
>
>> It's quite apparent some people around here cannot understand the very
>> basics about C++ arrays. :-)
>
> And it's quite apparent that you are one of them.
>
Oh yeah , well I seem to be correcting you alot lately.
Leigh Johnston
Proven wrong about what exactly? Where is this proof?
/Leigh
Paul
> On Mar 17, 8:28 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>
>> I have this array:
>
>> int (*array)[4] = new int[4][4];
>> ++array;
>> array[-1][3] = 4;
>
>> Is this an array? Or is it not an array?
>
> Is what an array or not?
mean?
> What you allocated is an array. The
> variable "array" is a pointer, not an array (as sizeof(array)
> will clearly show).
>
>> Also I have another array:
>
>> int* arr1 = new int[12];
>> arr1[0] = 33;
>> int* arr2 = new(++arr1) int[11];
>> std::cout<< arr2[-1];
>
> I'm not sure, but I think that last line has undefined behavior.
> The array new operator returns a pointer to the *first* element
> of an array.
Its not undefined at all, it's defined in the C++ standard as :
*((arr2)+(-1))
>
>> Is this an array or is it just a pointer?
>
> Again, is what an array or just a pointer.
Again, the entity I indexed with the expression arr2[-1], wtf do you think?
> All of the named
> variables in your code are pointers, not arrays.
>
So you think that when I index the array with arr2[-1], I do not index an
array?
Strange how it seems to return the correct values ..hmmm
>> Or as Noah says its a pointer that doesn't even point to an
>> array. Surely this is pushing the limits of plain idiocy. :-)
>
> An int* is a pointer. It may point to the first element of an
> array (or anywhere inside an array, for that matter), but it is
> and remains a pointer to a single int.
>
No it can point to an array. The C++ standard clearly states that :
"the newexpression yields a pointer to the initial element (if any) of the
array. [Note: both new int and new int[10] have type int* and the type of
new int[i][10] is int (*)[10]. ]"
Strange how you seem to have changed colors on this , it doesn't seem that
long ago that I stuck in to support you when you were having the exact same
argument with Leigh. And you said
Voila! when I posted code to support you.
Paul
> On 18/03/2011 00:03, Paul wrote:
>>
^^^^^^^^^^^^^^^
Paul
element of the array how can it not point to the array?
Leigh Johnston
What nonsense exactly? The only nonsense I see is the stuff you post.
/Leigh
Paul
> On Mar 17, 10:10 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
>
>> news:vfadnXg83rtyHh_Q...@giganews.com...
>
>> > On 17/03/2011 21:45, Paul wrote:
>
> [...]
>> >> This means that
>> >> int* x = new int[12];
>
>> >> Yields a pointer to an array. Not to *any* memory location.
>
>> > x is a pointer to a scalar not a pointer to an array; the scalar just
>> > happens to be the first element of an array.
>
>> You are wrong to say that its not a pointer to the array ref C++
>> standards:
>> "the newexpression yields a pointer to the initial element (if any) of
>> the
>> array."
>
> Reread that, please. The new expression yields a pointer to the
> initial element. Not to the array, but to just one element of
> the array.
>
What are you talking about , if its pointing ot the first element of the
array it is also pointing to the array.
duh
Is that Leigh hacked into James account or something.
> [...]
>> Obviously the function parameter should be char p[].
>
> When the top level type of a function parameter is an array, it
> is converted to a pointer. You cannot declare a function which
> has a parameter of array type. In other words:
> void f(char p[]);
> and
> void f(char*p);
> declare exactly the same function.
>
> In one of your examples, you used `cout << typeid(p).name()'.
> Try it on a local variable with an array type, on a local
> variable with pointer type, and on a function parameter declared
> as an array.
>
I already have and your point is?
Peter Remmers
> You still seem a bit unclear whether or not the array is received by
> function, you state the function receives a char*(not an array). The way you
> said it seemed to imply what I put in brackets.
Yes, it receives a pointer to one single lonely int, and it cannot
possibly know whether that poor little int has any neighbours and if so,
how many. The function can go ahead and assume anything it wants, and
try to access as many presumed neighbours as it likes, but unless the
programmer encodes their knowledge of the code outside the function into
these accesses, it is all but certain to be UB.
> Am I correct in assuming you think the array I passed is not an array
> (inside the function) because i passed a pointer to it?
Yes, inside the function there is only a pointer to one int, which does
indeed have neighbours, but that knowledge gets lost through the
function call.
> You think the array is not an array anymore for some reason?
The array is still there, but the knowledge about it does not cross the
point of the function invocation.
It is actually the same with operator new, just reversed. Operator new
creates an array, but it returns a pointer to only one int. From that
pointer alone you would not know how many elements follow the int. You
only know the secret number because you told operator new how many
elements you want, and you can only assume it followed your request.
I agree you're indexing the array there. But you only do that indirectly
through pointer arithmetic on "p". And you do that with the assumption
that p indeed points to an element of an array and that element has the
neighbors you're trying to access.
Actually, in this case a single int would really suffice, and your
access is well defined, as you're using an offset of zero (barring of
course things like NULL pointers and invalid pointers).
Peter
Paul
Good, but I see a "but" coming, so before I read the rest of this. Let me
tell you this , I *am* indexing the array.
> But you only do that indirectly through pointer arithmetic on "p".
It doesn't matter how I do it, I am definately indexing an array, you even
agree with that.
> And you do that with the assumption that p indeed points to an element of
> an array and that element has the neighbors you're trying to access.
p points to an array yes.
> Actually, in this case a single int would really suffice, and your access
> is well defined, as you're using an offset of zero (barring of course
> things like NULL pointers and invalid pointers).
>
So you agree that term p[0] indexes an array , right we can now move on....
Does the two array access expressions yield the same array indices or not?
:
p[0];
++p;
p[-1];
Stuart Golodetz
a) Try both 'int *x' and 'int (*x)[10]' at http://www.cdecl.org/
b) Consider the difference between types and values. A variable of type
'int *' is a pointer to an int, regardless of the value it contains, but
it may point at either an individual int, or an element of an array of
ints, or indeed somewhere completely invalid. To say that a variable of
type 'int *' that contains the address of the first element of an array
of ints 'points at the array' is to some extent an understandable
colloquialism, but it's imprecise. The pointer points at the first int
in the array, because by type it is a pointer to an (one, singular) int.
The key point is that whatever *value* I store in the pointer at
runtime, I can't change its *type* (types are compile-time entities). In
the following, both x and y have the same type:
int *x = new int;
int *y = new int[23];
They are both pointers to a single int. At runtime, x contains the
address of an individual int, and y contains the address of an int that
happens to be the first element of an int array. If you want to
colloquially describe that situation by saying 'y points to the array',
then that's up to you (most people would probably understand what you
meant), but formally speaking it's not the case.
Regards,
Stu
Stuart Golodetz
It's all to do with types. The same value can mean different things
depending on how you're interpreting it.
Suppose i is an int and p is an int*. Both contain the value 23 (say).
But the two variables are not the same: p points at the int at memory
location 23, whereas i only contains a number. i doesn't point anywhere,
because it's an int.
Now suppose x is of type int* and y is of type int (*)[9]. Both contain
the value 1984 (say). But the two variables are not the same: x points
at the int at memory location 1984, whereas y points at the array of 9
ints at memory location 1984. They point to the same place (1984), but
they're pointing at different things, because their *types* are
different - what they are pointing at depends not on the values they
contain, but on their types.
Your contention is that if there is an array starting at memory location
1984 and int *x contains the address 1984, then x 'points to the array'.
In the simple sense of 'hey, there's the array, and x contains what is
effectively a big arrow to where the array begins', this is an
understandable viewpoint, but in terms of its *type*, x points to an int
(the first element of the array).
Bottom line: The *value* x contains is irrelevant; it points to the sort
of entity its *type* tells you it does (in this case, a single int).
Regards,
Stu
Paul
"Stuart Golodetz" <bl...@blah.com> wrote in message
news:iluit6$3b4$1...@speranza.aioe.org...
int it's an array of int's.
int* x = new int[64];
This creates an array, not a single int. It's nonsense to suggest this
points to a single integer when it obviously points to the first int in an
array.
Paul
> 'int *' is a pointer to an int, regardless of the value it contains, but
> it may point at either an individual int, or an element of an array of
> ints, or indeed somewhere completely invalid. To say that a variable of
> type 'int *' that contains the address of the first element of an array of
> ints 'points at the array' is to some extent an understandable
> colloquialism, but it's imprecise. The pointer points at the first int in
> the array, because by type it is a pointer to an (one, singular) int.
>
> The key point is that whatever *value* I store in the pointer at runtime,
> I can't change its *type* (types are compile-time entities). In the
> following, both x and y have the same type:
>
> int *x = new int;
> int *y = new int[23];
>
> They are both pointers to a single int.
No this is wrong, y is a pointer to the first element in an array of ints,
not a single int.
You are correct to say they are the same types but they point to different
entities.
>At runtime, x contains the address of an individual int, and y contains the
>address of an int that happens to be the first element of an int array. If
>you want to colloquially describe that situation by saying 'y points to the
>array', then that's up to you (most people would probably understand what
>you meant), but formally speaking it's not the case.
Formally speaking it is exactly the case that y points to an array. It's
techincally incorrect to suggest it doesn't because the standards say that
it points to the initial element *of an array*.
cg_chas
wrote:
Paul,
I've read this entire thread and despite knowing that you are going to
argue no matter what logic is presented to you, I will go ahead and
present some anyway, since this case is clear.
int *x = new int;
int *y = new int[23];
Given both initializations, both x and y are pointers to a single int.
Sure, the address at which y resides may be the first element of an
array of contiguously allocated memory, but the pointer itself is
IDENTICAL to x with regards to its type.
Proof.
#include <iostream>
#include <typeinfo>
int main()
{
int *x = new int;
int *y = new int[23];
std::cout << "x type is : " << typeid(x).name() << std::endl;
std::cout << "y type is : " << typeid(y).name() << std::endl;
return 0;
}
Output is as follows..
x type is : int *
y type is : int *
Additionally, If the type pointed to was not the same then x++ and y++
would not increment the same number of bytes, but in fact, they do.
Why? becuse they are the same pointer type.
If you acknowledge that the pointer type is the same (which you do -
see above), then like it or not, you acknowledge that both cases point
to a single int. The logic is inescapable.
Your semantics are equivalent to and equally insignificant as saying
that every location pointed to by an int * is the first element of its
own array of one element. Sure, it may be true in a meaningful
context, but it does not change what an int pointer is or what an int
pointer points to.
An int pointer points to an int. "An" meaning single.
No spin, no argument, no form of semantics or troll-like logic is
going to change what an int pointer is. It is irrefutable.
Have a nice day and happy trolling.
Chas
Martijn van Buul
> Err no your nonsense is becoming beyond belief .
Not again :-/
--
Martijn van Buul - pi...@dohd.org
Stuart Golodetz
The first int in an array *is* a single int :) It's not two ints, three
ints, 64 ints or a million ints. It's a single darn int. The fact that
it may be followed in memory by other ints doesn't alter that fact.
On the other hand, if by "It" in "It's not a single int..." you mean the
array, then I agree with you. Evidently :)
Stuart Golodetz
Depends on your definition of "single". The first element in an array of
ints is an int (indisputable). The first element is also a singular
entity (that is, there is only one of it). I thus describe it as a
"single int" - it is one, and only one, int.
It is however arguable that you could define "single" to mean "stands
alone in memory, away from any other ints", i.e. this int is a rock, it
is an island. In that sense, my calling the first element of an array a
"single int" might perhaps have a tendency to confuse some people.
Regardless, I intended the first meaning, which I hope I have now
clarified :)
> You are correct to say they are the same types but they point to
> different entities.
Depends on what you mean by "point to". Technically speaking, they both
point at an int. One of those ints just happens to be at the start of an
array.
>> At runtime, x contains the address of an individual int, and y
>> contains the address of an int that happens to be the first element of
>> an int array. If you want to colloquially describe that situation by
>> saying 'y points to the array', then that's up to you (most people
>> would probably understand what you meant), but formally speaking it's
>> not the case.
>
> Formally speaking it is exactly the case that y points to an array. It's
> techincally incorrect to suggest it doesn't because the standards say
> that it points to the initial element *of an array*.
The initial element of an array is not an array. And on that note, I'm
off to play squash :) Bored already.
Paul
int's. :)
> On the other hand, if by "It" in "It's not a single int..." you mean the
> array, then I agree with you. Evidently :)
OFC it's there is only one reasonable way to look at it.
int x= new int;
int y = new int[16];
It is technically incorrect to suggest y doesn't point to an array of
integers because technically it does. And also as per the C++ standards it
does because the C++ standards say something like ..new returns a pointer ot
the first element *of the array*.
Look at the following:
a /*Here you see a single a*/
aaaaaaaaaaaaaaaaaaaaaa /*Here you see an array of a's*/
Why do they find it so hard to understand? I honestly cannot believe how
thick anyyone can be, and I don't mean to be nasty or rude towards them but
genuinely I am truly shocked at their low level of intelligence
Leigh Johnston
Negative subscripts are fine in pointer arithmetic but not when indexing
an array so those two pointer deferences are fine and do refer to the
same object. Again: a pointer is not an array and array is not a pointer.
HTH.
/Leigh
SG
> I honestly cannot believe how thick anyyone can be, [...]
> I am truly shocked at their low level of intelligence
So, you
(1) admit to being an amateur programmer who did not write (much)
C++ code during the past 10 years and admit to have learned C++
from a book called "Turbo C++ 3.0" which appears to have been
released 7 years before the C++ language became an ISO standard,
(2) perceive a bunch of C++ programmers (including professional ones)
to be much dumber than you,
(3) acknowledge the unbelievably low likelihood of everyone of them
being so much dumber than you
and the only conclusion you can draw is that everyone of them must
actually be so much dumber than you, even though (1) and (3) suggest
that you may have missed something in your analysis. It does not look
like self-reflection was part of your analysis.
SG
Paul
You suggest the entity pointed to is alway a single int, but that is not the
case with arrays.
>> You are correct to say they are the same types but they point to
>> different entities.
>
> Depends on what you mean by "point to". Technically speaking, they both
> point at an int. One of those ints just happens to be at the start of an
> array.
No one of them points to the initial element of an array. It doesn't just
happen to be the intiall element, it is defined in the C++ standard that it
will point to the initial element.
The other points to a single integer.
I could say you *just happen to be* incorrect about this. *shrug*
>
>>> At runtime, x contains the address of an individual int, and y
>>> contains the address of an int that happens to be the first element of
>>> an int array. If you want to colloquially describe that situation by
>>> saying 'y points to the array', then that's up to you (most people
>>> would probably understand what you meant), but formally speaking it's
>>> not the case.
>>
>> Formally speaking it is exactly the case that y points to an array. It's
>> techincally incorrect to suggest it doesn't because the standards say
>> that it points to the initial element *of an array*.
>
> The initial element of an array is not an array.
A pointer to the intial element of a array is a pointer to the array. It's
quite simple.
> And on that note, I'm off to play squash :) Bored already.
>
Glad your going because you make no sense at all. :-)
If you have a row of squash courts together like an array of squash courts,
which many of these places have.
[ ][ ][ ][ ][ ]
Stand outside these squashcourts and look at them as a group and point to
one of those courts with your finger. whilst standing there ask yourself..
Am I pointing to the squash courts(plural) or the squash court(singular)?
THe only reasonable answer is that you are pointing to both.
Leigh Johnston
No; "pointing to an array of squash courts" is different to "a pointer
to an array of squash courts". This subtle difference is the cause of
your misunderstanding IMO.
/Leigh
Paul
> On 18/03/2011 01:04, Paul wrote:
>>
>> So you agree that term p[0] indexes an array , right we can now move
>> on....
>> Does the two array access expressions yield the same array indices or
>> not?
>> :
>> p[0];
>> ++p;
>> p[-1];
>
> Negative subscripts are fine in pointer arithmetic but not when indexing
> an array so those two pointer deferences are fine and do refer to the same
> object.
>Again: a pointer is not an array and array is not a pointer.
This definitive distinction between pointer and array that you are trying to
make is a falsity.
I am using the pointer to index an array.
Paul
"SG" <s.ges...@gmail.com> wrote in message
news:fefac035-5cf9-42db...@z20g2000yqe.googlegroups.com...
> On 18 Mrz., 13:00, Paul wrote:
>> I honestly cannot believe how thick anyyone can be, [...]
>> I am truly shocked at their low level of intelligence
>
> So, you
>
> (1) admit to being an amateur programmer who did not write (much)
> C++ code during the past 10 years and admit to have learned C++
> from a book called "Turbo C++ 3.0" which appears to have been
> released 7 years before the C++ language became an ISO standard,
>
whatever version it was)?
So everyone who learned C++ pre-standards , are crap programmers IYO?
> (2) perceive a bunch of C++ programmers (including professional ones)
> to be much dumber than you,
>
Well that's how it appears to be doesn't it :-)
Leigh Johnston
>
> "SG" <s.ges...@gmail.com> wrote in message
> news:fefac035-5cf9-42db...@z20g2000yqe.googlegroups.com...
>> On 18 Mrz., 13:00, Paul wrote:
>>> I honestly cannot believe how thick anyyone can be, [...]
>>> I am truly shocked at their low level of intelligence
>>
>> So, you
>>
>> (1) admit to being an amateur programmer who did not write (much)
>> C++ code during the past 10 years and admit to have learned C++
>> from a book called "Turbo C++ 3.0" which appears to have been
>> released 7 years before the C++ language became an ISO standard,
>>
> You think there is something wrong with learning C++ with Turbo C++ 3.0(
> or whatever version it was)?
> So everyone who learned C++ pre-standards , are crap programmers IYO?
Not crap programmers per se but certainly crap at posting to a newsgroup
where ISO C++ is on topic.
>
>
>> (2) perceive a bunch of C++ programmers (including professional ones)
>> to be much dumber than you,
>>
> Well that's how it appears to be doesn't it :-)
>
Your trolls are very weak and too obvious... getting bored.
/Leigh
Stuart Golodetz
The subtle difference is between the following two definitions:
1) For p to point to x, p must contain the address of x.
2) For p to point to x, p must not only contain the address of x, p must
also be of the correct type.
Consider:
#include <iostream>
int main()
{
int a[3];
int *p = &a[0]; // or just 'a'
int (*q)[3] = &a;
std::cout << p << ' ' << q << '\n';
return 0;
}
This prints out the same value twice -- &a[0] and &a have the same
*value*, but different *type*. By definition (1), both p and q point to
a. By definition (2), only q points to a, because p's type dictates that
it points to an int.
One can define "points to" either way (indeed any way one likes), but
definition (2) highlights that there is a difference between the way in
which p and q "point to" a, whereas definition (1) does not. For the
purposes of being precise when there may be ambiguity involved,
definition (2) thus appears preferable in more formal discussion. PMMV
(Paul's mileage may vary).
Leigh Johnston
Unfortunately although your description seems to describe Paul's
misunderstanding perfectly he will still disagree due to the fact that
he is troll (in addition to being clueless).
/Leigh
Stuart Golodetz
> On 18/03/2011 15:28, Stuart Golodetz wrote:
>> On 18/03/2011 13:44, Leigh Johnston wrote:
That hadn't been entirely lost on me :) Just figured I'd at least
provide some clarity for the benefit of anyone else who might happen to
be reading the thread.
Cheers,
Stu
Stuart Golodetz
Note, incidentally, that I'm not saying that you can't say that "p
points to a", just that it's a colloquial usage of "points to" that
fails to fully capture the subtleties involved. In informal conversation
between people who understand the context, it may be an acceptable
colloquialism. For the purposes of e.g. standards documents, it's not.
Stu
cg_chas
>The subtle difference is between the following two definitions:
>
>1) For p to point to x, p must contain the address of x.
>
>2) For p to point to x, p must not only contain the address of x, p must
>also be of the correct type.
>
>Consider:
>
>#include <iostream>
>
>int main()
>{
> int a[3];
> int *p = &a[0]; // or just 'a'
> int (*q)[3] = &a;
> std::cout << p << ' ' << q << '\n';
> return 0;
>}
>
>This prints out the same value twice -- &a[0] and &a have the same
>*value*, but different *type*. By definition (1), both p and q point to
>a. By definition (2), only q points to a, because p's type dictates that
>it points to an int.
>
>One can define "points to" either way (indeed any way one likes), but
>definition (2) highlights that there is a difference between the way in
>which p and q "point to" a, whereas definition (1) does not. For the
>purposes of being precise when there may be ambiguity involved,
>definition (2) thus appears preferable in more formal discussion. PMMV
>(Paul's mileage may vary).
Well put Stuart.
Incrementing each of the two different pointers further asserts that
the type pointed two is singularly dependent on the pointer type.
i.e. definition (2)
Since the pointer types are different (int * versus int (*)[3]), a
single increment will assign different values to each pointer.
p++;
q++;
std::cout << p << ' ' << q << '\n';
output on my machine:
0022F9C8 0022F9D0
Again, irrefutable logic food for the troll.
Paul may be well fed at this point, but at some point, he's going to
realize this thread is a permenant record of his ignorance.
Chas
cg_chas
wrote:
or a pointer to his ignorance if anybody is still amused by pedantry..
Stuart Golodetz
<snip>
>>
>> Again, irrefutable logic food for the troll.
>>
>> Paul may be well fed at this point, but at some point, he's going to
>> realize this thread is a permenant record of his ignorance.
>>
>> Chas
>
> or a pointer to his ignorance if anybody is still amused by pedantry..
Always :)
Paul
> On 18/03/2011 13:44, Leigh Johnston wrote:
>> On 18/03/2011 13:39, Paul wrote:
int* p = new int[16];
Creates a 1dim int array, and is identified by a int* type;
int(*)[16] would be the type of identifier for a 2dim array as follows:
int (*p2)[16] = new int[3][16];
A 2dim int array is identified by an int(*)[size] type.
Just accept this and move on before you become even more confused about
arrays and pointers and what they point to.
cg_chas
wrote:
Paul,
It is interesting that you use the word confusion to desribe the state
of mind of a person whose response to you was both logical and
correct. This in itself is quite revealing.
Perhaps you should start listening to those with clear and pervasive
knowledge of the language before spouting off details that fail to
support your claim "that an array is just a pointer".
you said,
>A 2dim int array is identified by an int(*)[size] type.
This is the same thing as saying that a pointer of array type points
to an array. i.e. which is just another assertion that Stuart's
definition (2) is entirely valid.
I personally find humor in the fact that you've managed to assert
Stuart's case that a pointer of a given type points to the correct
type, in the same breath that you call him confused.
This is why you're a mere troll with weak kung fu.
Regardless of how you choose to state the obvious, you fail to assert
your claim that an array is just a pointer.
OTOH, I will demonstrate your incorrectness.
Given pointer p2 whose type is int(*)[16] that has been initialized to
the address of the first element of the int[3][16] array, which in
this case is an element of array type, clearly itself is not the same
as the array itself. If the array was just a pointer, then the array
and pointer would share the same size.
int (*p2)[16] = new int[3][16];
std::cout << "p2 type is : " << typeid(p2).name() << std::endl;
std::cout << sizeof(int) << std::endl;
std::cout << sizeof(int) * 3 * 16 << std::endl;
std::cout << sizeof(p2) << std::endl;
output on my machine:
p2 type is : int (*)[16]
4
192
4
Further elaboration states that p2 can also be expressed an int[16]*
or a pointer to an array of 16 ints and that the pointer itself has no
awareness that storage for 16*3 ints were allocated.
Regardless of your desire to spin semantics, you can have pointers to
pointers, arrays of arrays, pointers to arrays, arrays of pointers,
and an infinite permutation of the former, but the pointer is not
itself an array any more than the array itself a pointer.
You fight irrefutable logic with misguided abstraction, sir.
Chas
SG
>
> int* p = new int[16];
> Creates a 1dim int array, and is identified by a int* type;
>
> int(*)[16] would be the type of identifier for a 2dim array as follows
> int (*p2)[16] = new int[3][16];
> A 2dim int array is identified by an int(*)[size] type.
This is the kind of terminology misuse that is indicative of your
incompetence. You may be able to write working C++ programs. But you
don't seem able to talk about C++ (and by that I mean the correct use
of well-established terminology).
A "type" never "identifies" an "array". Saying otherwise only makes
sense in *your* head. And instead of using the word "identifier" you
should have used the word "variable", at least in this context.
Instead of "is identified by" you should have said something along the
lines of "is accessable by". Instead of "by a T type" you should have
said "by a variable of type T" or "by an instance of T" or "by a T
instance". The use of "T type" to mean "T instance" or "instance of T"
is, again, misuse of the word "type".
> Just accept this
There is no reason to prefer your vague and twisted terminology over
the C++ ISO standard's terminology.
SG
Paul
"cg_chas" <cg_...@hotmail.com> wrote in message
news:j147o653kvn01mf8l...@4ax.com...
and obvious its just big pile of disagreements an arguments that try to
stats my opinions as incorrect.
So lets see , what exactly is he saying and what exactly is he trying to say
is incorrect? He seems very unsure of himself.
> Paul,
>
> It is interesting that you use the word confusion to desribe the state
> of mind of a person whose response to you was both logical and
> correct. This in itself is quite revealing.
>
Blleeurg
> Perhaps you should start listening to those with clear and pervasive
> knowledge of the language before spouting off details that fail to
> support your claim "that an array is just a pointer".
>
Bleeeurg.
> you said,
>>A 2dim int array is identified by an int(*)[size] type.
Yes I did, its clearly stated above.
>
> This is the same thing as saying that a pointer of array type points
> to an array. i.e. which is just another assertion that Stuart's
> definition (2) is entirely valid.
No its probably not the same as whatever that means in your mind.
>
> I personally find humor in the fact that you've managed to assert
> Stuart's case that a pointer of a given type points to the correct
> type, in the same breath that you call him confused.
>
Blueeerg
> This is why you're a mere troll with weak kung fu.
>
> Regardless of how you choose to state the obvious, you fail to assert
> your claim that an array is just a pointer.
>
Blueeerg
> OTOH, I will demonstrate your incorrectness.
>
LOL Ok here we go , lets see firstly what exactly is he saying I am
incorrect about here? I don't know. ^_^.
> Given pointer p2 whose type is int(*)[16] that has been initialized to
> the address of the first element of the int[3][16] array, which in
> this case is an element of array type, clearly itself is not the same
> as the array itself.
Correct
> If the array was just a pointer, then the array
> and pointer would share the same size.
No don't be stupid, why does the pointer need to be the same size as the
array?
>
> int (*p2)[16] = new int[3][16];
> std::cout << "p2 type is : " << typeid(p2).name() << std::endl;
> std::cout << sizeof(int) << std::endl;
> std::cout << sizeof(int) * 3 * 16 << std::endl;
> std::cout << sizeof(p2) << std::endl;
>
> output on my machine:
> p2 type is : int (*)[16]
> 4
> 192
> 4
And what exactly is that piece of code suppoed to prove?
Some Blueerg about sizeof different types?
>
> Further elaboration
What exactly have you elaborated on so far?
>states that p2 can also be expressed an int[16]*
> or a pointer to an array of 16 ints and that the pointer itself has no
> awareness that storage for 16*3 ints were allocated.
>
> Regardless of your desire to spin semantics, you can have pointers to
> pointers, arrays of arrays, pointers to arrays, arrays of pointers,
> and an infinite permutation of the former, but the pointer is not
> itself an array any more than the array itself a pointer.
>
Bleurgh
> You fight irrefutable logic with misguided abstraction, sir.
>
ok thanks for that , now you have a nice day :-)
cg_chas
>Before you go any further I just had a quick scan over the jist of your post
>and obvious its just big pile of disagreements an arguments that try to
>stats my opinions as incorrect.
>So lets see , what exactly is he saying and what exactly is he trying to say
>is incorrect? He seems very unsure of himself.
It seems that you quick scan everything. The C++ standard seems to be
no exception. Perhaps this is why your lack of comprehension is
bested only by your lack of maturity.
If you're going to make an assertion or make a claim as you did with
this thread, then make it and support it with logic. Where is your
supporting logic?
>> It is interesting that you use the word confusion to desribe the state
>> of mind of a person whose response to you was both logical and
>> correct. This in itself is quite revealing.
>>
>Blleeurg
Lol, you win this point. I rarely stand up to a monkey throwing its
feces.
>
>> Perhaps you should start listening to those with clear and pervasive
>> knowledge of the language before spouting off details that fail to
>> support your claim "that an array is just a pointer".
>>
>
>Bleeeurg.
more feces. I'll concede this point to.
>
>> you said,
>>>A 2dim int array is identified by an int(*)[size] type.
>
>Yes I did, its clearly stated above.
>
>>
>> This is the same thing as saying that a pointer of array type points
>> to an array. i.e. which is just another assertion that Stuart's
>> definition (2) is entirely valid.
>
>No its probably not the same as whatever that means in your mind.
You should thank me for not criticising your choice of wording here,
after all, I am really only interested in seeing your proof of your
claim.
I was kind for giving you the benefit of the doubt as your use of the
"identified" has no place in a C++ discussion. A "quick scan" of the
standard perhaps was not enough for you.
Since however, you are disagreeing with the fact that a pointer of
array type points to an array of the proper type then I will say that
your statement above is somewhere between irrelevant and incorrect,
but in either case, not in any way assertive to your claim that "An
array is just a pointer"
>> OTOH, I will demonstrate your incorrectness.
>>
>LOL Ok here we go , lets see firstly what exactly is he saying I am
>incorrect about here? I don't know. ^_^.
>
>> Given pointer p2 whose type is int(*)[16] that has been initialized to
>> the address of the first element of the int[3][16] array, which in
>> this case is an element of array type, clearly itself is not the same
>> as the array itself.
>Correct
>> If the array was just a pointer, then the array
>> and pointer would share the same size.
>
>No don't be stupid, why does the pointer need to be the same size as the
>array?
It is you that says that "An array is just a pointer".
If not in size then what characteristic of an array, in your mind,
gives it equality with a pointer?
You have yet to provide any coherent proof of this, yet others have in
fact disproved it over and over.
Paul
> On 18 Mrz., 17:41, Paul wrote:
>>
>> int* p = new int[16];
>> Creates a 1dim int array, and is identified by a int* type;
>>
>> int(*)[16] would be the type of identifier for a 2dim array as follows
>> int (*p2)[16] = new int[3][16];
>> A 2dim int array is identified by an int(*)[size] type.
>
> This is the kind of terminology misuse that is indicative of your
> incompetence. You may be able to write working C++ programs. But you
> don't seem able to talk about C++ (and by that I mean the correct use
> of well-established terminology).
>
Err hold on, all this type nonsense has been introduced by you(see comment)
. I am simply trying to expalin how thinks work in your terms.
Comment: You or people on your side of the argument.
I know the type of the array is int, in this case, and thats all the type
info I need to know.
> A "type" never "identifies" an "array". Saying otherwise only makes
> sense in *your* head.
An array can be identified by a pointer of type int*.
int* p = new int[16];
p[0] = 0;
In the above expression the identifier 'p' is used as an identifier for the
array. In this case the identifier is also a type int*.
I think this is all pedantic language bullshit but this type of discussion
has not been introduced by me.
> And instead of using the word "identifier" you
> should have used the word "variable", at least in this context.
> Instead of "is identified by" you should have said something along the
> lines of "is accessable by". Instead of "by a T type" you should have
> said "by a variable of type T" or "by an instance of T" or "by a T
> instance". The use of "T type" to mean "T instance" or "instance of T"
> is, again, misuse of the word "type".
>
As I said above the identifier "p" is a pointer type. I don't see what is
wrong with this statement.
int* p;
What type is "p"? It's a poiner type. Where is the confusion?
>> Just accept this
>
> There is no reason to prefer your vague and twisted terminology over
> the C++ ISO standard's terminology.
>
There is nothing vague and twisted about what I have said. It's quite normal
terminology.
Its similar to a Cat object:
class Animal{};
class Cat:public Animal{};
Animal* p = new Cat;
Here p points to a Cat object , but its type is Animal*.
In this case it can be said that p is a Cat because the pointer points to a
Cat. Its simply a shorthand way of saying the entity pointed to by p is a
Cat object.
Because its an Animal-pointer-type doesn't mean it can't point to a Cat
object.
Just google "passing an array to a function in C++" and you will see that ,
when a pointer represents an array, when such a pointer is dereferenced it
yields the arrays data. Therefore hundreds of programmers refer to such a
pointer as simply an array for example in the following code:
void foo(int* p){
for(int i=0; i<=10; ++i){ p[i] =i;}
}
int* p = new int[11];
foo(p);
Inside this fucntion I can safely say that I have looped through the array.
Yes its obviously a pointer but it's also an array. :-)
Paul
>
<snip>.
>
>>
>>> you said,
>>>>A 2dim int array is identified by an int(*)[size] type.
>>
>>Yes I did, its clearly stated above.
>>
>>>
>>> This is the same thing as saying that a pointer of array type points
>>> to an array. i.e. which is just another assertion that Stuart's
>>> definition (2) is entirely valid.
>>
>>No its probably not the same as whatever that means in your mind.
>
> You should thank me for not criticising your choice of wording here,
> after all, I am really only interested in seeing your proof of your
> claim.
>
> I was kind for giving you the benefit of the doubt as your use of the
> "identified" has no place in a C++ discussion. A "quick scan" of the
> standard perhaps was not enough for you.
>
> Since however, you are disagreeing with the fact that a pointer of
> array type points to an array of the proper type then I will say that
> your statement above is somewhere between irrelevant and incorrect,
> but in either case, not in any way assertive to your claim that "An
> array is just a pointer"
>
>>> OTOH, I will demonstrate your incorrectness.
>>>
>>LOL Ok here we go , lets see firstly what exactly is he saying I am
>>incorrect about here? I don't know. ^_^.
>>
>>> Given pointer p2 whose type is int(*)[16] that has been initialized to
>>> the address of the first element of the int[3][16] array, which in
>>> this case is an element of array type, clearly itself is not the same
>>> as the array itself.
>>Correct
>>> If the array was just a pointer, then the array
>>> and pointer would share the same size.
>>
>>No don't be stupid, why does the pointer need to be the same size as the
>>array?
> It is you that says that "An array is just a pointer".
>
But how do you come to the conclusion that this would mean a pointer to an
array is the same size as the array it points to?
> If not in size then what characteristic of an array, in your mind,
> gives it equality with a pointer?
>
I think the question here is what is going on in your mind to make you think
that a pointerto an array should be the same size as the array it points to?
> You have yet to provide any coherent proof of this, yet others have in
> fact disproved it over and over.
Proof of what?
Proof that a pointerto an array is not the same size as an array?
int* p_to_array = new int[16];
std::cout<< "sizeof pointer:\t"<<sizeof ( p_to_array)<< std::endl;
std::cout << "sizeof array:\t" <<sizeof(p_to array) * 16;
Is that good enough for you?
cg_chas
wrote:
>
>"SG" <s.ges...@gmail.com> wrote in message
>news:86435af6-122c-4993...@d28g2000yqc.googlegroups.com...
>> On 18 Mrz., 17:41, Paul wrote:
>>>
>>> int* p = new int[16];
>>> Creates a 1dim int array, and is identified by a int* type;
>>>
>>> int(*)[16] would be the type of identifier for a 2dim array as follows
>>> int (*p2)[16] = new int[3][16];
>>> A 2dim int array is identified by an int(*)[size] type.
>>
>> This is the kind of terminology misuse that is indicative of your
>> incompetence. You may be able to write working C++ programs. But you
>> don't seem able to talk about C++ (and by that I mean the correct use
>> of well-established terminology).
>>
>
>Err hold on, all this type nonsense has been introduced by you(see comment)
>. I am simply trying to expalin how thinks work in your terms.
Instead of trying to guess what terms might be for understandable to
your reader in your explanations, perhaps do as SG suggests and stick
to terminology that is used in the standard.
>> A "type" never "identifies" an "array". Saying otherwise only makes
>> sense in *your* head.
>
>An array can be identified by a pointer of type int*.
No, it cannot.
An array is not "identified " by a pointer.
Pointers do not "identify".
If the array is pointed to by a pointer of array type then
dereferencing said pointer returns the array. Only the array that is
the type of the pointer is returned.
If the the array is pointed to by a pointer of int type then
dereferencing said pointer returns an int value. Only the int value
that is the type of pointer is returned.
>
>int* p = new int[16];
>p[0] = 0;
>
>In the above expression the identifier 'p' is used as an identifier for the
>array. In this case the identifier is also a type int*.
>I think this is all pedantic language bullshit but this type of discussion
>has not been introduced by me.
Actually, of all the people that have taken the time to respond to
you, you're the only one making up bullshit terms instead of using
more well defined ones.
>Just google "passing an array to a function in C++" and you will see that ,
>when a pointer represents an array, when such a pointer is dereferenced it
>yields the arrays data.
You seem to thrive on the ambiguity that a pointer "represents" or
"identifies" an array.
Only pointers of an array type point to an array of said type.
Only pointers of an array type return an array of data when
dereferenced.
> Therefore hundreds of programmers refer to such a
Lol @ hundreds.
>pointer as simply an array for example in the following code:
>
>void foo(int* p){
> for(int i=0; i<=10; ++i){ p[i] =i;}
>}
>
>int* p = new int[11];
>foo(p);
>
>Inside this fucntion I can safely say that I have looped through the array.
Yes you have looped through an array, one element at a time using a
pointer to a single element each iteration.
>Yes its obviously a pointer but it's also an array. :-)
It is ONLY a pointer, which was used a pointer to a single element
multiple times in a loop. In no way does this make it an array.
Basically, we come to the conclusion now that your logic is as
follows.
Since we can pass a pointer to first element of an array to a function
and loop indexing the array with a pointer, then the pointer must be
an array?
Sorry Paul, this just is not correct.
Accessing arrays with pointers and operators does not make the arrays
themselves pointers.
cg_chas
>> It is you that says that "An array is just a pointer".
>>
>I didn't say this. That is just the subject of the discussion.
It is the subject of YOUR discussion and you have said it numerous
times. At least do the world the courtesy of owning your own
bullshit.
>But how do you come to the conclusion that this would mean a pointer to an
>array is the same size as the array it points to?
I do not come to that conclusion. I only assert that the conclusion
must be true if the statement you made in the subject of this
discussion is true and it is not.
>
>
>> If not in size then what characteristic of an array, in your mind,
>> gives it equality with a pointer?
>>
>I think the question here is what is going on in your mind to make you think
>that a pointerto an array should be the same size as the array it points to?
see above..
>
>
>> You have yet to provide any coherent proof of this, yet others have in
>> fact disproved it over and over.
>
>Proof of what?
proof that "An array is just a pointer". You can only attempt to deny
that you started the thread predicated on an incorrect statement, but
the fact remains, it is incorrect.
>Proof that a pointerto an array is not the same size as an array?
>
>int* p_to_array = new int[16];
>std::cout<< "sizeof pointer:\t"<<sizeof ( p_to_array)<< std::endl;
>std::cout << "sizeof array:\t" <<sizeof(p_to array) * 16;
>
>Is that good enough for you?
>
Your endless trolling.. I alread proved the size difference. In fact
that proof invalidated the statement that is the subject of this
thread which is YOUR thread.
Your reading comprehension is as equally inept as your logic and
reasoning skills. Not that this surprises me, but I got the response
I needed in your response to SG. I responded there and refuted your
failing logic one and for all.
It was anticlimatic after all, but at least we got to the bottom of
your confusion.
Leigh Johnston
>
> "cg_chas" <cg_...@hotmail.com> wrote in message
> news:rla7o6pfpetf8cvud...@4ax.com...
>> fact disproved it over and over.
>
> Proof of what?
> Proof that a pointerto an array is not the same size as an array?
>
> int* p_to_array = new int[16];
> std::cout<< "sizeof pointer:\t"<<sizeof ( p_to_array)<< std::endl;
> std::cout << "sizeof array:\t" <<sizeof(p_to array) * 16;
>
> Is that good enough for you?
>
Good enough? It is plain wrong; what you should have wrote was:
std::cout << "sizeof array:\t" <<sizeof(p_to_array[0]) * 16;
Try harder (after you have learnt pointer basics).
/Leigh
Paul
>
>>> It is you that says that "An array is just a pointer".
>>>
>>I didn't say this. That is just the subject of the discussion.
>
> It is the subject of YOUR discussion and you have said it numerous
> times. At least do the world the courtesy of owning your own
> bullshit.
Please show me where I have said this.
The subject of the discussion is not a statement of fact, I did not state
whether I agreed with this or not.
I would certainly never say an array is *just* a pointer, although i do
understand the underlying mechanics of the C++ language that allows a
pointer to be used as an array.
>
>>But how do you come to the conclusion that this would mean a pointer to an
>>array is the same size as the array it points to?
>
> I do not come to that conclusion. I only assert that the conclusion
> must be true if the statement you made in the subject of this
> discussion is true and it is not.
>
So you have come to this conclusion then :-S
>>
>>
>>> If not in size then what characteristic of an array, in your mind,
>>> gives it equality with a pointer?
>>>
>>I think the question here is what is going on in your mind to make you
>>think
>>that a pointerto an array should be the same size as the array it points
>>to?
>
> see above..
>
>>
>>
>>> You have yet to provide any coherent proof of this, yet others have in
>>> fact disproved it over and over.
>>
>>Proof of what?
>
> proof that "An array is just a pointer". You can only attempt to deny
> that you started the thread predicated on an incorrect statement, but
> the fact remains, it is incorrect.
>
I have never said an array is *just* a pointer.
>>Proof that a pointerto an array is not the same size as an array?
>>
>>int* p_to_array = new int[16];
>>std::cout<< "sizeof pointer:\t"<<sizeof ( p_to_array)<< std::endl;
>>std::cout << "sizeof array:\t" <<sizeof(p_to array) * 16;
>>
>>Is that good enough for you?
>>
>
> Your endless trolling.. I alread proved the size difference. In fact
> that proof invalidated the statement that is the subject of this
> thread which is YOUR thread.
>
> Your reading comprehension is as equally inept as your logic and
> reasoning skills. Not that this surprises me, but I got the response
> I needed in your response to SG. I responded there and refuted your
> failing logic one and for all.
>
> It was anticlimatic after all, but at least we got to the bottom of
> your confusion.
Bluueerg
cg_chas
wrote:
>
>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:q8f7o6lghqkg56se1...@4ax.com...
>>
>>>> It is you that says that "An array is just a pointer".
>>>>
>>>I didn't say this. That is just the subject of the discussion.
>>
>> It is the subject of YOUR discussion and you have said it numerous
>> times. At least do the world the courtesy of owning your own
>> bullshit.
>
>Please show me where I have said this.
your response to SG and i quote "its obviously a pointer but it's also
an array"
>The subject of the discussion is not a statement of fact, I did not state
>whether I agreed with this or not.
So the world gets to guess which statements you make you are choosing
to stand by as factual and which are there for what? your trolling
entertainment?
Your entire debate has supported, albeit poorly, the statement in the
subject.
>> I do not come to that conclusion. I only assert that the conclusion
>> must be true if the statement you made in the subject of this
>> discussion is true and it is not.
>>
>So you have come to this conclusion then :-S
I can only assume this is a troll response since it is clear that I
have not come to that conclusion. I stand by the data output that I
posted.
>I have never said an array is *just* a pointer.
The comic value of you saying this is priceless.
You can say this until you are blue in the face, but the subject which
has your statement in it says otherwise.
Paul
Says who?
Err no
A pointer of type int(*)[10] doesn't point to an array of type int[10], it
points to an array of type int[i][10];
You do not seem to understand that pointers to arrays point to an array of
n-1 dimensional array.
And pointers(of any type) do not return an array of data when they are
dereferenced.
8.3.4
"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."
Please get your facts right before preaching about proper use of the
language terminology.
>> Therefore hundreds of programmers refer to such a
> Lol @ hundreds.
>>pointer as simply an array for example in the following code:
>>
>>void foo(int* p){
>> for(int i=0; i<=10; ++i){ p[i] =i;}
>>}
>>
>>int* p = new int[11];
>>foo(p);
>>
>>Inside this fucntion I can safely say that I have looped through the
>>array.
> Yes you have looped through an array, one element at a time using a
> pointer to a single element each iteration.
>
>>Yes its obviously a pointer but it's also an array. :-)
> It is ONLY a pointer, which was used a pointer to a single element
> multiple times in a loop. In no way does this make it an array.
No its a pointerto an array.
>
> Basically, we come to the conclusion now that your logic is as
> follows.
>
> Since we can pass a pointer to first element of an array to a function
> and loop indexing the array with a pointer, then the pointer must be
> an array?
>
> Sorry Paul, this just is not correct.
> Accessing arrays with pointers and operators does not make the arrays
> themselves pointers.
Nobody is saying the array is a pointer.
I think you should hang your head in shame for a while, after this post, and
listen to someone who knows better instead of trying preach about things you
are not clear on.
After making the statements above ref:
" Only pointers of an array type point to an array of said type.
Only pointers of an array type return an array of data when
dereferenced"
You obviously are being misguided by the likes of Leigh Johnston and other
people who are twisting words around and declaring falsities.
Paul
> On Fri, 18 Mar 2011 20:31:16 -0000, "Paul" <pchr...@yahoo.co.uk>
> wrote:
>
>>
>>"cg_chas" <cg_...@hotmail.com> wrote in message
>>news:q8f7o6lghqkg56se1...@4ax.com...
>>>
>>>>> It is you that says that "An array is just a pointer".
>>>>>
>>>>I didn't say this. That is just the subject of the discussion.
>>>
>>> It is the subject of YOUR discussion and you have said it numerous
>>> times. At least do the world the courtesy of owning your own
>>> bullshit.
>>
>>Please show me where I have said this.
> your response to SG and i quote "its obviously a pointer but it's also
> an array"
>
>>The subject of the discussion is not a statement of fact, I did not state
>>whether I agreed with this or not.
> So the world gets to guess which statements you make you are choosing
> to stand by as factual and which are there for what? your trolling
> entertainment?
>
> Your entire debate has supported, albeit poorly, the statement in the
> subject.
>
No it hasn't, my subject line is a bit of a joke TBH.
I think I have made my views clear about this and I would never say an array
is just a pointer.
>>> I do not come to that conclusion. I only assert that the conclusion
>>> must be true if the statement you made in the subject of this
>>> discussion is true and it is not.
>>>
>>So you have come to this conclusion then :-S
> I can only assume this is a troll response since it is clear that I
> have not come to that conclusion. I stand by the data output that I
> posted.
>
So did you come to a conclusion or not?
>>I have never said an array is *just* a pointer.
> The comic value of you saying this is priceless.
>
> You can say this until you are blue in the face, but the subject which
> has your statement in it says otherwise.
>
No the subject is not a statemnt of my opinion. I am stating my opinion now
and its not up to you to decide.
Leigh Johnston
Wrong again; you don't understand pointers (or types) at all.
[...]
>
> You obviously are being misguided by the likes of Leigh Johnston and
> other people who are twisting words around and declaring falsities.
Untrue and also libelous if it wasn't so obvious that you are a fool
that cannot be taken seriously.
/Leigh
Leigh Johnston
> On 18/03/2011 20:47, Paul wrote:
[...]
>> Err no
>> A pointer of type int(*)[10] doesn't point to an array of type int[10],
>> it points to an array of type int[i][10];
>
> Wrong again; you don't understand pointers (or types) at all.
>
Why you are wrong:
int a1[10];
int (*p1)[10] = &a1; // type of 'p1' is pointer to an array of 10 ints
int a2[42][10];
int (*p2)[10] = &a2[0]; // type of 'p2' is also pointer to an array of
10 ints
int (*p3)[10] = new int[42][10]; // type of 'p3' is also pointer to an
array of 10 ints
// 'p1', 'p2' and 'p3' are all the *same* type namely a pointer to an
array of 10 ints
/Leigh
Paul
nonsensical argument I am having to put up with.
Paul
8.3.4
"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."
I think this concludes my case, and I hope this will end the nonsensical
arguements of these confused individuals :-)
Paul
8.3.4
"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."
Leigh Johnston
Why does that make me wrong? That part of the Standard you have quoted
is talking about what happens to the pointer resulting from an
"array-to-pointer conversion".
Why you are still wrong:
If the * operator is applied to p1, p2 or p3 above the result will be a
reference to an array of 10 ints; i.e. the following assertion holds:
assert(sizeof(*p1) == sizeof(*p2) && sizeof(*p2) == sizeof(*p3) &&
sizeof(*p3) == sizeof(int[10]));
>
>
> I think this concludes my case, and I hope this will end the nonsensical
> arguements of these confused individuals :-)
Unfortunately nothing has been concluded as you still lack proper
understanding of the issue under discussion.
/Leigh
cg_chas
>> An array is not "identified " by a pointer.
>> Pointers do not "identify".
>
>Says who?
place of terms that have a strict meaning.
>> Only pointers of an array type point to an array of said type.
>> Only pointers of an array type return an array of data when
>> dereferenced.
>>
>Err no
>A pointer of type int(*)[10] doesn't point to an array of type int[10], it
>points to an array of type int[i][10];
I said, "said type". You have changed my statement based on what is
going on in your head.
At least you are starting to use proper terminology, so progress has
been made.
A pointer of type int(*)[10], also the same as int[10]*, points to an
array of 10 int.
int a[10];
int *p = &a[0]; // or just 'a'
int (*q)[10] = &a;
std::cout << p << ' ' << q << '\n';
std::cout << "p type is : " << typeid(p).name() << std::endl;
std::cout << "q type is : " << typeid(q).name() << std::endl;
int n = static_cast<int>(sizeof(int));
std::cout << sizeof(*q) / n << std::endl;
output on my machine:
p type is : int *
q type is : int (*)[10]
10
I stand by my statement that a pointer of array type points to an
array of the said type.
>You do not seem to understand that pointers to arrays point to an array of
>n-1 dimensional array.
Sure I do.
>And pointers(of any type) do not return an array of data when they are
>dereferenced.
You get the array when you dereference a pointer to an array.
>
>8.3.4
>"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."
>
>Please get your facts right before preaching about proper use of the
>language terminology.
You seem to think that by making truthful statements that you lessen
your own visibility with regards to your poor use of programming and
spoken languages.
>
>
>
>>> Therefore hundreds of programmers refer to such a
>> Lol @ hundreds.
>>>pointer as simply an array for example in the following code:
>>>
>>>void foo(int* p){
>>> for(int i=0; i<=10; ++i){ p[i] =i;}
>>>}
>>>
>>>int* p = new int[11];
>>>foo(p);
>>>
>>>Inside this fucntion I can safely say that I have looped through the
>>>array.
>> Yes you have looped through an array, one element at a time using a
>> pointer to a single element each iteration.
>>
>>>Yes its obviously a pointer but it's also an array. :-)
>> It is ONLY a pointer, which was used a pointer to a single element
>> multiple times in a loop. In no way does this make it an array.
>
>No its a pointerto an array.
You said, "but it's also an array".
>Nobody is saying the array is a pointer.
So you're saying that a pointer is an array, but an array is not a
pointer?
Either way, you're incorrect. Own your statements already.
>
>I think you should hang your head in shame for a while, after this post
If I were to hang my head in shame, it would be for allowing your
incompetence to occupy any of my time at all, but to be honest, I
cannot resist such an easy target. You sir are a live one.
Paul
What part of this don't you understand?
The pointer points to an array of dim n, if you dereference it either
implciity or explicitily , the pointer points to an array of dim n-1.
Duh you just don't get it do you.
I will explain again:
int (*p)[10] = new int[3][10];
This pointer points an array of type int[3][10], that is a 2Dim array.
It doesn't point to an array of of type int[10].
The pointer *type* does not deifne the type of array it points to. The
pointer type is an n-1 dim type.
> assert(sizeof(*p1) == sizeof(*p2) && sizeof(*p2) == sizeof(*p3) &&
> sizeof(*p3) == sizeof(int[10]));
>
What is that bollocks about? ^^^^^^
>>
>>
>> I think this concludes my case, and I hope this will end the nonsensical
>> arguements of these confused individuals :-)
>
> Unfortunately nothing has been concluded as you still lack proper
> understanding of the issue under discussion.
>
I understood this concept when I explained it to bigger people than you a
long time ago. At least they grasped the concept eventually, you don't seem
to be able to grasp it at all.
Paul
>
>>> An array is not "identified " by a pointer.
>>> Pointers do not "identify".
>>
>>Says who?
> Says anybody tired of seeing you use your own language semantics in
> place of terms that have a strict meaning.
>
>>> Only pointers of an array type point to an array of said type.
>>> Only pointers of an array type return an array of data when
>>> dereferenced.
>>>
>>Err no
>>A pointer of type int(*)[10] doesn't point to an array of type int[10],
>>it
>>points to an array of type int[i][10];
> I said, "said type". You have changed my statement based on what is
> going on in your head.
>
> At least you are starting to use proper terminology, so progress has
> been made.
>
> A pointer of type int(*)[10], also the same as int[10]*, points to an
> array of 10 int.
>
When it's dereferenced it points to an array of int[10] type.
8.3.4
"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."
<snip>
cg_chas
>Duh you just don't get it do you.
>I will explain again:
>
>int (*p)[10] = new int[3][10];
>This pointer points an array of type int[3][10], that is a 2Dim array.
>It doesn't point to an array of of type int[10].
Absolutely incorrect.
p has only been initialized to the first element of the first array in
the array of int[3][10] and therefore can only point to the first
array of 10 ints.
p most certainly points to an array of 10 ints or int[10] and that is
all it points to.
The fact that new has allocated storage beyond p's type declaration is
irrelevant.
Paul
Leigh Johnston
Again that part of the Standard is talking about what happens to the
pointer resulting from an "array-to-pointer conversion".
>
> Duh you just don't get it do you.
It is obvious to all that it is *you* that doesn't "get it".
> I will explain again:
>
> int (*p)[10] = new int[3][10];
> This pointer points an array of type int[3][10], that is a 2Dim array.
Wrong; p is a pointer to an array of type int[10].
> It doesn't point to an array of of type int[10].
Yes it does.
>
> The pointer *type* does not deifne the type of array it points to. The
> pointer type is an n-1 dim type.
Yes it does; in your example the pointer is a pointer to an array of
type int[10] which points to a sub-array of type int[10] which is an
element of the larger int[3][10] array.
>
>
>> assert(sizeof(*p1) == sizeof(*p2) && sizeof(*p2) == sizeof(*p3) &&
>> sizeof(*p3) == sizeof(int[10]));
>>
> What is that bollocks about? ^^^^^^
That "bollocks" is an attempt to explain things to you in terms of the
C++ language as you seem to have problems with the English language.
>
>>>
>>>
>>> I think this concludes my case, and I hope this will end the nonsensical
>>> arguements of these confused individuals :-)
>>
>> Unfortunately nothing has been concluded as you still lack proper
>> understanding of the issue under discussion.
>>
> I understood this concept when I explained it to bigger people than you
> a long time ago. At least they grasped the concept eventually, you don't
> seem to be able to grasp it at all.
>
It is you who is failing to grasp what others are trying to explain to you.
/Leigh
Leigh Johnston
>
> "cg_chas" <cg_...@hotmail.com> wrote in message
> news:ujh7o6dvp5b7mbmtg...@4ax.com...
>>
>>>> An array is not "identified " by a pointer.
>>>> Pointers do not "identify".
>>>
>>> Says who?
>> Says anybody tired of seeing you use your own language semantics in
>> place of terms that have a strict meaning.
>>
>>>> Only pointers of an array type point to an array of said type.
>>>> Only pointers of an array type return an array of data when
>>>> dereferenced.
>>>>
>>> Err no
>>> A pointer of type int(*)[10] doesn't point to an array of type
>>> int[10], it
>>> points to an array of type int[i][10];
>> I said, "said type". You have changed my statement based on what is
>> going on in your head.
>>
>> At least you are starting to use proper terminology, so progress has
>> been made.
>>
>> A pointer of type int(*)[10], also the same as int[10]*, points to an
>> array of 10 int.
>>
> No you are wrong. it points to an array of type int[i][10].
> When it's dereferenced it points to an array of int[10] type.
When a pointer of type int(*)[10] is dereferenced the result is not a
pointer so it doesn't point to anything; the result of the dereference
is a reference of type int[10].
/Leigh
Paul
are. I've explained it enough times I'm not explaining it again
Paul
int (*x)[10] = new int[3][10];
If x is dereferenced like so ...x[0] , x is converted to a pointer to
int[10]. This means x is not a pointer to int[10] to begin with.
It's a pointer to int[3][10].
Work it out dummy.
cg_chas
wrote:
>
>"cg_chas" <cg_...@hotmail.com> wrote in message
>news:m1m7o6trmpearhe7c...@4ax.com...
>>
>>>Duh you just don't get it do you.
>>>I will explain again:
>>>
>>>int (*p)[10] = new int[3][10];
>>>This pointer points an array of type int[3][10], that is a 2Dim array.
>>>It doesn't point to an array of of type int[10].
>>
>> Absolutely incorrect.
>>
>> p has only been initialized to the first element of the first array in
>> the array of int[3][10] and therefore can only point to the first
>> array of 10 ints.
>>
>> p most certainly points to an array of 10 ints or int[10] and that is
>> all it points to.
>>
>> The fact that new has allocated storage beyond p's type declaration is
>> irrelevant.
>>
>Learn the language properly kid.
I was born in 1970 and started programming in 1986. If that makes me a
kid, then I'll take it.
As far as your repeatedly quoting the section of the stardard that
gives a rule for indexing multidimensional arrays, feel free to quote
all you want. You are however, misquoting and our out of context.
The section you keep incessantly pasting refers a rule for indexing
n-1 dimensional arrays.
The code above and that is in the context of this discussion is
initializing a pointer of int[10] type to a single array because that
is the type we have declared.
No conversion is necessary. We declared and allowed new to initialize
what part of the allocated space we are going to point to.
p is our pointer and its being initialized to the first element of the
first array only. p has no knowledge of any other arrays.
OTOH new certainly did when it allocated int[3][10], but p does not.
cg_chas
>what part of the allocated space we are going to point to.
pointer to the portion of the space allocated.
Leigh Johnston
Wrong; x is not converted to a pointer to int[10] as it is *already* a
pointer to int[10]; x[0] is a reference to an int[10] array as
sizeof(x[0]) will confirm.
> Work it out dummy.
Follow your own advice.
/Leigh
Paul
refuse to listen.
GL
Paul
Here x is a 3 в 5 array of ints; more precisely, x is an array of three
element objects, each of which is an array of five ints. In the expression
x[i], which is equivalent to (*((x)+(i))), x is first converted to a pointer
to the initial array of five ints.
It cannot be any clearer than that.
GL
Leigh Johnston
Yes that part of the standard is quite clear; I am not sure why you are
quoting it though as nobody has contradicted it as we are talking about
something different. An array is not a pointer; the Standard's
description of what happens (or an equivalence of what happens) when
subscripting an array does not invalidate this axiom.
>
> GL
>
You are the one who needs *lots* of luck.
HTH.
/Leigh
Paul
> On 18/03/2011 22:55, Paul wrote:
<quote ref="Leigh">
>> Wrong; x is not converted to a pointer to int[10] as it is *already* a
>> pointer to int[10]; x[0] is a reference to an int[10] array as
>> sizeof(x[0]) will confirm.
The C++ standards directly contradict what you think.
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> > Reread that, please. The new expression yields a pointer to the
> > initial element. Not to the array, but to just one element of
> > the array.
> What are you talking about , if its pointing ot the first
> element of the array it is also pointing to the array.
Only in the sense that it is also pointing to an unsigned char,
and who knows what all else. The physical pointer is pointing
to some place in memory, which can, as far as the hardware is
concerned, be anything.
In C++, pointers have a type. And an int is not an array, and
if the pointer points to an int, it cannot point to an array,
because an int is not an array.
--
James Kanze
Leigh Johnston
Nothing in that quote is "utter bollocks"; if x is of type int(*)[10]
then it is already a pointer to int[10] and x[0] is a reference to an
int[10] array as sizeof(x[0]) will still confirm. I hate having to
repeat myself to clueless individuals.
>
> The C++ standards directly contradict what you think.
>
I see no contradiction; as I said that quote is correct.
/Leigh
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> > You just contradicted your previous statement. An array new
> > expression yields a pointer to the first element of the allocated
> > array, not a pointer to the array. Pointer arithmetic and how
> > arrays are laid out in memory allow us to use that pointer to
> > access other elements of the array.
> In what way have i condracted anything?
If the pointer points to an element of the array, it doesn't
point to the array. A pointer points to exactly one thing, and
only one thing.
> > [...]
> >> void foo(int p[]){
> >> std::cout<< p << typeid(p).name();
> >> }
> >> int main()
> >> {
> >> int arr[];
> >> foo("Is this an array?" );
> >> }
> >> Is an array passed to foo,
> > It can't be. The standard explicitly says that arrays can't be
> > passed as arguments.
> Where? Can you show me the quote.
§8.3.5/3: "After determining the type of each parameter, any
parameter of type “array of T” or “function returning T” is
adjusted to be “pointer to T” or “pointer to function returning
T,” respectively."
Since you can't declare a function with a parameter type that is
an array, you can't pass an array as an argument.
> You are obviously speaking utter nonsense. I can pass a array
> by reference.
You can pass a reference to an array, but you can't pass the
array itself.
> >> has an array been processed by cout? Of course it
> >> has.
> > No. There's a special rule that says that arrays can't be passed
> > to functions. (Pointers to arrays, and references to arrays,
> > yes, but not arrays.)
> SO you can pass a pointer to an array, that is called passing
> by reference.
No. Passing by reference is when you pass a reference. But in
C++, passing a reference is still distinct from passing the
object itself.
Still, I'll grant you the pass by reference point: if the
function is declared to take a reference to an array, you can
pass it an array (by reference).
> >> See the C++ standards to confirm the definition of string literals and
> >> character arrays.
> > But you can't pass a string literal or a character array to a
> > function.
> I just did .
No. Since there was no operator<< which takes an array (by
reference or otherwise), the compiler tried all possible
implicit conversions to find a match. You actually passed the
operator<< a pointer, not an array.
> >> It's quite apparent some people around here cannot
> >> understand the very basics about C++ arrays. :-)
> > And it's quite apparent that you are one of them.
> Oh yeah , well I seem to be correcting you alot lately.
With erroneous statements.
--
James Kanze
James Kanze
> "James Kanze" <james.ka...@gmail.com> wrote in message
> news:481675f6-0b1b-4da6...@w21g2000yqm.googlegroups.com...>
> On Mar 17, 8:28 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> >> I have this array:
> >> int (*array)[4] = new int[4][4];
> >> ++array;
> >> array[-1][3] = 4;
> >> Is this an array? Or is it not an array?
> > Is what an array or not?
> The entity I indexed with the expression array[-1][3], wtf do
> you think i mean?
If you indexed it, it couldn't be an array, because C++ doesn't
have an operator which indexes into an array.
> > What you allocated is an array. The variable "array" is a
> > pointer, not an array (as sizeof(array) will clearly show).
> >> Also I have another array:
> >> int* arr1 = new int[12];
> >> arr1[0] = 33;
> >> int* arr2 = new(++arr1) int[11];
> >> std::cout<< arr2[-1];
> > I'm not sure, but I think that last line has undefined behavior.
> > The array new operator returns a pointer to the *first* element
> > of an array.
> Its not undefined at all, it's defined in the C++ standard as :
> *((arr2)+(-1))
Yes, but the standard says that pointers have bounds. A pointer
points into an array, and pointer arithmetic is not allowed to
take it outside of the array, except for one past the end. (For
purposes of pointer arithmetic, a scalar behaves like an array
of one element.) The pointer returned by new ... int[11] points
to the first element of an array of 11 elements. All pointer
arithmetic on it is required to remain in the bounds of those 11
elements.
> >> Is this an array or is it just a pointer?
> > Again, is what an array or just a pointer.
> Again, the entity I indexed with the expression arr2[-1], wtf
> do you think?
Since the expression arr2[-1] has undefined behavior, it doesn't
"index" anything. And if you're being really strict, there is
no "indexing": you've dereferenced the results of pointer
arithmetic. Except that this particular bit of pointer
arithmetic results in undefined behavior. According to the
standard---there aren't many implementations where it won't work
like you seem to think.
> > All of the named
> > variables in your code are pointers, not arrays.
> So you think that when I index the array with arr2[-1], I do
> not index an array?
No. C++ doesn't support indexing into an array. It just
doesn't exist.
> Strange how it seems to return the correct values ..hmmm
Undefined behavior can result in anything.
> >> Or as Noah says its a pointer that doesn't even point to an
> >> array. Surely this is pushing the limits of plain idiocy. :-)
> > An int* is a pointer. It may point to the first element of an
> > array (or anywhere inside an array, for that matter), but it is
> > and remains a pointer to a single int.
> No it can point to an array.
Not if the type is int*. It points to an int, and an int is
*not* an array.
> The C++ standard clearly states that :
> "the newexpression yields a pointer to the initial element (if any) of the
> array. [Note: both new int and new int[10] have type int* and the type of
> new int[i][10] is int (*)[10]. ]"
Exactly. The new expression yields a pointer to the initial
element of an array. Not to the array.
--
James Kanze
Paul
"James Kanze" <james...@gmail.com> wrote in message
news:41127c54-9ea9-4067...@e8g2000vbz.googlegroups.com...
to.
I'd have thought you'd know better but obviously I had a high regard for you
than you deserved.