«

Dale wrote:
> Mark McIntyre <> wrote in
> news::
>
>>On 08 Oct 2005 19:26:59 GMT, in comp.lang.c , Dale <>
>>wrote:
>>
>>>Mark McIntyre <> wrote in
>>>news: :
>>>
>>>>Actually, no, this is terribly terribly wrong. In neither declaration
>>>>is 'x' a pointer - its an array[4] of char.
>>>
>>>You're the one who's wrong, here, ****nut
>>
>>You're amusingly wrong, as well as abusive.
>
> Too bad you can't prove me wrong, huh, Mr. Thinskin.

Mark is far from being thin skinned, he is also correct.

>>Arrays are not pointers.
>
> I've already shown that an identifier declared as an array of characters is
> a character type pointer.

Several people explained why your code does *not* show that.

> You have failed to demonstrate otherwise.

You have already been informed by several highly skilled people that you
were wrong, and I mentioned that the is covered in the comp.lang.c FAQ.
Here is the URL to the actual question since you seem incapable of
checking yourself http://www.eskimo.com/~scs/C-faq/q6.9.html

Also in section 6.2.5 Types of the current C standard (google for
n1124.pdf to get the draft of the next version for free) it describes
array and pointer types separately and never says they are the same. The
same goes for the rest of the standard, it never says they are the same
and says when and how arrays names get *converted* to pointers.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Dale wrote:
>
> I've already shown that an identifier declared as an array of
> characters is a character type pointer. You have failed to
> demonstrate otherwise.

Actually he did demonstrate otherwise but you decided to snip
it. Here's another demonstration:

int main(void)
{
char x[10];
char **p = &x; /* compiler error */
}

Perhaps you'd like to explain why that fails to compile,
Mr. Smarty-pants.

On 7 Oct 2005 06:02:00 -0700, "werasm" <> wrote in
comp.lang.c:

>
> Davy wrote:
> > Hi all,
> >
> > I found
> > char x[4]={"my"};
> > can be compiled.
>
> Yes, but it is better to do this:
>
> char x[] = "my";
>
> This way just enough space for "my" is provided.
>
> > But
> > char x[4];
> > x={"my"};
> > can not be compiled.
>
> Because the type of x in...
>
> char x[4];
>
> ...is effectively...
>
> char* const x;

No, it is not. 'x' is not a pointer, not any kind of pointer to
anything.

> ...which means the value of the pointer "x" is constant - may not be
> modified, whereas doing this...

The statement above has no meaning, since there is no 'pointer "x"'.

> x={"my"}; //- actually x = "my"...
>
> ...attemps to modify the pointer x, which is why you get a compiler
> error.

Except that, once again, there is no 'pointer x'. 'x' is the name of
a region of storage that is large enough to store four chars. There
is no pointer involved.

> Suggestions as follow:
>
> char x[100] = { '\0' };
> std:strstream os( x, sizeof(x) );
> os << "Hooh, hah" << std::ends; //don't forget std::ends;
>
> or...
>
> std::string x("my");
>
> or...
>
> char x[4] = { '\0' };
> strcpy( x, "my" );
>
> Remember, the contents of the array which exists at the address
> location whereto x points, is modifiable. The address itself (or the

But 'x' does not point to anything.

> value of the ptr) is not.

There is no 'ptr' (sic).

> Regards,
>
> W

It is posts like this that help keep the confusion about arrays and
pointers worse than it has to be.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

> No, it is not. 'x' is not a pointer, not any kind of pointer to
> anything.

Hi Jack,

According to Bjarne Stroustrup:

"The name of an array can be used as a pointer to its initial element."

In my own words - "The name of an array is implicitly convertable to a
pointer pointing to the address location of its first element..."

While I do understand that x is in actual fact "the name of a region
that is large enough to store four chars" - or simply the name of an
array of characters of for elements, my point remains that, in contrast
to this case...

char* x = new char[4];

.... the type of x in case...

char x[4];

....is very similar (or effectively the same as) to...

char* const x = new char[4];

I did not say exactly the same (or equivalent to) - but reacts the same
in that one cannot do this:

char* const x( 0 );
char* y( new char [4] );
x = y;

Which would help (I hope) the initial poster to understand it a little
better (IMHO) - especially the reason for his compilation error.

>> It is posts like this that help keep the confusion about arrays and
>> pointers worse than it has to be.

I disagree with this. The fact that the type <char[4]> is implicitly
convertable ot <char*> is confusing. Using my explanation, I attempt to
clarify it to c++ users that find it confusing. If you feel that I've
failed to do so (clarify), suit yourself.

Thank you for your response anyway. Agreed - but my posting was misread
by you - I feel.

Regards,

W

"werasm" <> writes:
>> No, it is not. 'x' is not a pointer, not any kind of pointer to
>> anything.
>
> Hi Jack,
>
> According to Bjarne Stroustrup:
>
> "The name of an array can be used as a pointer to its initial element."
>
> In my own words - "The name of an array is implicitly convertable to a
> pointer pointing to the address location of its first element..."

Yes, in most contexts.

> While I do understand that x is in actual fact "the name of a region
> that is large enough to store four chars" - or simply the name of an
> array of characters of for elements, my point remains that, in contrast
> to this case...
>
> char* x = new char[4];
>
> ... the type of x in case...
>
> char x[4];
>
> ...is very similar (or effectively the same as) to...
>
> char* const x = new char[4];
>
> I did not say exactly the same (or equivalent to) - but reacts the same
> in that one cannot do this:
>
> char* const x( 0 );
> char* y( new char [4] );
> x = y;
>
> Which would help (I hope) the initial poster to understand it a little
> better (IMHO) - especially the reason for his compilation error.

Note that this thread is (unwisely) cross-posted to comp.lang.c and
comp.lang.c++. The C equivalent of "new char[4]" would be "malloc(4)"
(there are probably some subtle differences).

Saying that an array declaration is equivalent to a pointer
declaration is *exactly* what makes this area so confusing.
Attempting to view it that way makes it very difficult to understand
why sizeof(x) doesn't give you the size of the array, or why &x
doesn't give you the address of a pointer.

On the other hand, all these things follow naturally from an
understanding of what's really going on.

Namely:

Arrays are arrays. Pointers are pointers. They are not the same
thing; an array declaration creates an array object, *not* a pointer
object.

An expression of array type, in most contexts, is implicitly converted
to a pointer to the array's first element. This does not apply to the
operand of a unary "&" or "sizeof" operator, or to a string literal in
an initializer.

In addition (and somewhat confusingly), a function parameter declared
with what appears to be an array type is really of a pointer type.
This does *not* follow from other rules; it's an explicit special
case.

Finally, read section 6 of the C FAQ. (There's probably similar
information in the C++ FAQ.)

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

Keith Thompson wrote:

> Note that this thread is (unwisely) cross-posted to comp.lang.c and
> comp.lang.c++. The C equivalent of "new char[4]" would be "malloc(4)"
> (there are probably some subtle differences).

I don't really read comp.lang.c, therefore would not be aware of cross
posting. Yes, I know that C equivalent is malloc(4). I don't want to
debate these differences.

> An expression of array type, in most contexts, is implicitly converted
> to a pointer to the array's first element. This does not apply to the
> operand of a unary "&" or "sizeof" operator, or to a string literal in
> an initializer.

Yes, agreed - especially wrt. the "does not apply to" part, and well
said. Furthermore, you cannot assign <char*> type to char[] type. In
this respect, char[] type is similar to <char* const> type - similar,
not equivalent. I agree that mentioning it may be confusing.

> In addition (and somewhat confusingly), a function parameter declared
> with what appears to be an array type is really of a pointer type.

Yes, this I'm aware of - that is why it is a good idea to use a boost
array instead as argument - or a vector, where the type is more
explicit if your size is not known at compile time. In "C", I suppose
one would use, when working with arrays something to the effect of:

void foo( char[] array, unsigned sz );

> This does *not* follow from other rules; it's an explicit special
> case.

....and has been the root of many problems.

I have scanned the C++ FAQ's but could find anything of the cuff. I
personally have no problem with this. I'm in agreeance with what you've
said. Also with the way in which you have said it.

Thank you and kind regards,

W

werasm wrote:
>
> > No, it is not. 'x' is not a pointer, not any kind of pointer to
> > anything.
>
> Hi Jack,
>
> According to Bjarne Stroustrup:
>
> "The name of an array can be used as a pointer to its initial element."
>
> In my own words - "The name of an array is implicitly convertable to a
> pointer pointing to the address location of its first element..."
>
> While I do understand that x is in actual fact "the name of a region
> that is large enough to store four chars" - or simply the name of an
> array of characters of for elements, my point remains that, in contrast
> to this case...
>
> char* x = new char[4];
>
> ... the type of x in case...
>
> char x[4];
>
> ...is very similar (or effectively the same as) to...
>
> char* const x = new char[4];

Well. I see where you are heading at, but yet this is not true. The type
is convertible, but that's all. So whenever the compiler has an array[] type
and there is need to convert, eg. because a function accepts a pointer, the
compiler can do this under the hood. But never say: *an array is a pointer*
or varitions of that, since it is plain wrong.

eg.

abcd.h
******

char foo[] = { "hello" }; // declare an array

defgh.cpp
*********
#include <stdio.h>

extern char* foo;

int main()
{
printf( "%s", foo );
}

this will fail without a doubt for exactly that reason: an array is not a pointer,
not even close. But: In some cicumstances an array can act 'as if it were' a pointer.
AFAIK there were 2 resons for this:
* passing arrays to functions which K&R felt to not be necessary and thereby bypassing the
problem of what to do with non matching array sizes (that especially would have been a
problem with some character arrays acting as string storage).
* Array indexing is defined in terms of pointer arithmetic.
a[i] is equivalent to *(a+i)
(a beeing an array and i beeing an index).

Especially the last point is the explanation, why one can do:

char c = malloc(4);
c[3] = '\0';

The compiler immediatly transforms this to
*(c+3)
and applies the usual pointer arithmetic.
Doing the same with an array

char d[4];
d[3] = '\0'

again: The compiler transforms this into
*(d+3) = '\0'

and now the array to pointer conversion kicks in, and converts the array
to a pointer to its first element. Then the usual array arithmetic can be done.

But even if both versions look equivalent on the C source code level (or C++), the
generated machine code is usually different.

*(c+3) is converted to ( c beeing a 'real pointer')

fetch value for c
add 3
assign '\0' to that memory address

*(d+3) translates to:

load address of d
add 3
assign '\0' to that memory address

NB: If you have sorted out this issue with a newbie there is an easy way
to further confuse him. Introduce him to

char e[4];
3[e] = '\0';

and ask if it is valid and if yes, why?

--
Karl Heinz Buchegger

Keith Thompson wrote:

> Finally, read section 6 of the C FAQ. (There's probably similar
> information in the C++ FAQ.)

Have done so (now). You've quoted it almost exactly (if not).

I also noticed in (6.9) that my explanation have been used in the past
as simplification. I wonder why . People crawl before they walk.

When I still tried to understand what a pointer was (I have read many
definitions by now), I conceptualized it by reading a decription
stating that "a pointer is an integer whos value is an address". On
other occasions(much later), I was actually corrected when considering
a pointer as an integer. The fact remains that the original description
contributed to my understanding of pointers. Likewise, I do think that
my explanation contributes to understanding the reason why the original
posters problem did not compile. Whether you agree or not, this opinion
remains. I nevertheless appreciated your comments and references.

Kind regards,

W

Karl Heinz Buchegger wrote:
> abcd.h
> ******
>
> char foo[] = { "hello" }; // declare an array
>
> defgh.cpp
> *********
> #include <stdio.h>
>
> extern char* foo;
>
> int main()
> {
> printf( "%s", foo );
> }
>
> this will fail without a doubt for exactly that reason: an array is not a pointer,
> not even close. But: In some cicumstances an array can act 'as if it were' a pointer.

I absolutely agree . Have always.

> But even if both versions look equivalent on the C source code level (or C++), the
> generated machine code is usually different.
>
> *(c+3) is converted to ( c beeing a 'real pointer')
>
> fetch value for c
> add 3
> assign '\0' to that memory address
>
> *(d+3) translates to:
>
> load address of d
> add 3
> assign '\0' to that memory address

Interesting...

> char e[4];
> 3[e] = '\0';
>
> and ask if it is valid and if yes, why?

Yes, it is valid - because "array subscripting is commutive in C
(...and C++?)". Not common practice though, and you don't have to
consider yourself a newbie if you don't use (or did not know) this. In
fact, I've never come accross this in real code (code obfuscation
.... bad).

Also, the term newbie is relative... Maybe always considering oneself a
newbie is not a bad thing - at least your learn. Ditto for posting
answers to newbies. Our swearing friend (Dale) could learn from this.

Also, I suppose reading the FAQ's before posting the original question
would have been desirable.

Regards,

W

werasm wrote:
> Keith Thompson wrote:
>
>>Finally, read section 6 of the C FAQ. (There's probably similar
>>information in the C++ FAQ.)
>
> Have done so (now). You've quoted it almost exactly (if not).
>
> I also noticed in (6.9) that my explanation have been used in the past
> as simplification. I wonder why . People crawl before they walk.
>
> When I still tried to understand what a pointer was (I have read many
> definitions by now), I conceptualized it by reading a decription
> stating that "a pointer is an integer whos value is an address". On
> other occasions(much later), I was actually corrected when considering
> a pointer as an integer.

An easy way (in my opinion) to conceptualise a pointer is it is like
your finger. It might be pointing at a piece of paper where you scrawled
a number (directing you to read a number from the piece of paper when
you dereference it) or if it is a wild pointer it might be pointing in
to the wild blue yonder (there was a piece of paper with a number, but
it was incinerated when you freed it) or it might be a null pointer
which means it is not pointing anywhere.

Incrementing a pointer is then just moving your finger to point at the
next number on that piece of paper (array or allocated block) and then
it is obvious that you hit problems when you go passed the edge of the
paper.

> The fact remains that the original description
> contributed to my understanding of pointers. Likewise, I do think that
> my explanation contributes to understanding the reason why the original
> posters problem did not compile. Whether you agree or not, this opinion
> remains. I nevertheless appreciated your comments and references.

I've not read your original description (or not recently enough to
remember it) so I can't comment directly on it. However, if Kieth
pointed out problems in it then you should listen to him since he knows
what he is talking about.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.