An array is just a pointer

P

Paul

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?

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. :)
 
J

Juha Nieminen

Leigh Johnston said:
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).
 
P

Peter Remmers

Am 17.03.2011 21:28, schrieb Paul:
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
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
 
J

Juha Nieminen

Leigh Johnston said:
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).
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
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.

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. :)
 
N

Noah Roberts

Leigh Johnston said:
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.
 
P

Paul

Peter Remmers said:
Am 17.03.2011 21:28, schrieb Paul:
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
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. :)
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?");


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
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
On 17/03/2011 20:51, Juha Nieminen 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.
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."
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 is quite apparent to everyone who is lacking a clue here.
Yes you. :)
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
On 17/03/2011 21:45, Paul wrote:

On 17/03/2011 20:51, Juha Nieminen 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.
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."

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.
Err no "a pointer to the first element of an array" means exactly the same
thing as "a pointer to an array".
 
P

Paul

Leigh Johnston said:
On 17/03/2011 21:45, Paul wrote:

On 17/03/2011 20:51, Juha Nieminen 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.

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."

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.

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
}
This is a clear indication of how screwed up you are. Please read the
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[10] is
int (*)[10]. ]"


The standards define both of these types to be pointers to the array, they
are just different *types* of pointer.
 
P

Peter Remmers

Am 17.03.2011 23:00, schrieb Paul:
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
 
P

Paul

Leigh Johnston said:
Leigh Johnston said:
On 17/03/2011 22:14, Leigh Johnston wrote:
On 17/03/2011 22:10, Paul wrote:

On 17/03/2011 21:45, Paul wrote:

On 17/03/2011 20:51, Juha Nieminen 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.

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."

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.


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
}
This is a clear indication of how screwed up you are. Please read the
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[10] is
int (*)[10]. ]"


The standards define both of these types to be pointers to the array,
they are just different *types* of pointer.


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".


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.
 
J

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.
 
J

James Kanze

[...]
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.
 
J

James Kanze

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.
 
P

Paul

Peter Remmers said:
Am 17.03.2011 23:00, schrieb Paul:
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]) { .. }
I don't need to know the length of the array because I passed a unlll
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 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.


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?
 
P

Paul

Leigh Johnston said:
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.

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."

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.


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
}

This is a clear indication of how screwed up you are. Please read the
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[10] is
int (*)[10]. ]"


The standards define both of these types to be pointers to the array,
they are just different *types* of pointer.


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".


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.


Yes everything seems like nonsense to you as you are either unable or
unwilling to be get a firm technical grasp on C++ matters.

PROVEN WRONG!
 
J

James Kanze

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.
 
J

James Kanze

[...]
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?
 
P

Paul

James Kanze said:
On 17/03/2011 20:51, Juha Nieminen 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.

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.

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.

But you can't pass a string literal or a character array to a
function.
I just did .
And it's quite apparent that you are one of them.
Oh yeah , well I seem to be correcting you alot lately.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top