«

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

"Leigh Johnston" <> wrote in message
news:lo6dndXGO-...
> On 17/03/2011 22:34, Paul wrote:
>>
>> "Leigh Johnston" <> wrote in message
>> news: ...
>>> On 17/03/2011 22:14, Leigh Johnston wrote:
>>>> On 17/03/2011 22:10, Paul wrote:
>>>>>
>>>>> "Leigh Johnston" <> wrote in message
>>>>> news:vfadnXg83rtyHh_QnZ2dnUVZ8r-...
>>>>>> On 17/03/2011 21:45, Paul wrote:
>>>>>>>
>>>>>>> "Leigh Johnston" <> wrote in message
>>>>>>> news: ...
>>>>>>>> On 17/03/2011 20:51, Juha Nieminen wrote:
>>>>>>>>> Leigh Johnston<> 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[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.
>>
>
> 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.

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

On Mar 17, 8:51 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> 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

On Mar 17, 9:45 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Leigh Johnston" <le...@i42.co.uk> wrote in message

> news: ...

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

"Peter Remmers" <> wrote in message
news:4d829286$0$6770$...
> 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 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?

"Leigh Johnston" <> wrote in message
news: ...
> On 17/03/2011 23:00, Paul wrote:
>>
<prune>
>>>>>>>>>>>>
>>>>>>>>>>>> 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[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.
>>>>
>>>
>>> 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!

On Mar 17, 10:10 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Leigh Johnston" <le...@i42.co.uk> wrote in message

> news:vfadnXg83rtyHh_QnZ2dnUVZ8r-...

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

On Mar 17, 10:27 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "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

"James Kanze" <> wrote in message
news:1a3230b7-ce7c-4e38-b1dc-...
> On Mar 17, 9:45 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
>> "Leigh Johnston" <le...@i42.co.uk> wrote in message
>
>> news: ...
>
>> > 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.
>

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.