char* and char

[Ying Yang]

Hi,

whats the difference between:

char* a = new char;

char* b = new char[10];

char c [10];
Regards
BN

[David White]

White Wolf <wo***@freemail .hu> wrote in message
news:bk******** **@phys-news1.kolumbus. fi...

David White wrote:

I would think that people, newbies in particular, are interested in
all the differences betweeen pointers and arrays, not just those
where the name is used. I can see no good reason to single out uses
of the name alone.
You mean that we should not mention one very important rule of the

language just because at first sight it differs from other languages?
I didn't mention other languages. I paid no mind to other languages in
making that statement. Arrays and pointers have a whole bunch of properties.
If an array is involved in a particular operation, then particular behaviour
will result, whether its name is used or not. As long as you know what will
happen in a given circumstance, then I don't see why you would think in
terms of an array's name, unless you happen to find it easier to remember
everything that way.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay into a
pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array? The value of sizeof(*pc) suggests that it is. So
doesn't f(*pc) convert our unnamed array into a pointer to its first
element?

But if
you say, "An array decays to a pointer where a pointer is expected,"
you at least aren't making a false statement

You are. The array never decays into anything.

It was a poor choice of wording. Try again: "The use of an array where a
pointer is expected equates to the address of the array's first element."
T foo[S];

Suppose the above is an array declaration. The array is a variable. It has an object part (the associated continuous region of storage) and a name
part, which we use to refer to that storage and a type part, which tells
what is in that storage, how big that storage is etc.

The array is the object (the storage) with its type.
I'm aware of that. That's why I never think of arrays as pointers.
The word foo is the
name of the variable. We use the name of the variable to refer to the
storage. Now in some cases, foo refers to that storage as a pointer to its first element, while in another cases it represent the whole storage with
all the elements in it.

Okay, I'm happy with that, but I still don't particularly care about the
name. In some cases referring to the array, however that might be, results
in the address of its first element. Forget the name.

So far the exceptions in C++ are:
sizeof, address of, template parameter,

Yes.

default assignment of structs
and classes,

No. In the default assignment of classes the _name_ of the array is not
used.

So we just forget about that then? I didn't think the OP was asking about
names. I thought the question was about pointers and arrays. Default
assignment of structs needs to be learned as much as anything else.

DW

[Attila Feher]

David White wrote:

Arrays and pointers have a whole bunch of properties.
I am sorry but I have no idea what do you mean.
If an array is involved in a particular operation, then
particular behaviour will result, whether its name is used or not.
You have just said nothing.
As long as you know what will happen in a given circumstance,
then I don't see why you would think in terms of an array's
name, unless you happen to find it easier to remember
everything that way.
Because the rules are based on that. You could start to disregard traffic
lamps, because you think that instinct will drive you through the road
crossings better, but it is not a life insurance.

There is a simple trick to learn and understand the rules of arrays in C and
C++. It goes like this: learn and understand the rules of arrays in C and
C++. Of course you can choose a separate route and not learn them, but then
you will not know them.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay
into a pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array?

Yes. But you are still referring to an array in an expression. Whether the
reference takes the form of *pc or "My char array" it does not matter. It
is not the array which changes its type: only the way you refer to it
changes.
The value of sizeof(*pc) suggests that it is.
I am not exactly sure if it is right to call that an unnamed array. An
unnamed array should be an array temporary, and AFAIK those do not exist,
since you are unable to return arrays from functions. The closest thing I
can imagine is that character literal above.
So doesn't f(*pc) convert our unnamed array into a pointer to its
first element?
Not really. Not the array. The reference to it.

You are. The array never decays into anything.

It was a poor choice of wording. Try again: "The use of an array
where a pointer is expected equates to the address of the array's
first element."

Yep. That should work.

The array is the object (the storage) with its type.

I'm aware of that. That's why I never think of arrays as pointers.

Good. Now the next step is to do it also the other way around.
Okay, I'm happy with that, but I still don't particularly care about
the name. In some cases referring to the array, however that might
be, results in the address of its first element. Forget the name.
Okay. We forget it.

No. In the default assignment of classes the _name_ of the array is
not used.

So we just forget about that then?

OK. Forget. The *array* is *not* used either. Plain and simple. You use
a struct/class. The array type is used by the copy constructor or the
assignment operator of that class type. Very different situation.
I didn't think the OP was asking about names.
I thought the question was about pointers and arrays.
And I did not answer to the OP talking about names.
Default assignment of structs needs to be learned
as much as anything else.

There is no such thing in C++. structs are class types.

Anyway that has nothing to do with refering to an array and that reference
decaying to a pointer.

--
Attila aka WW

[David White]

"Attila Feher" <at**********@l mf.ericsson.se> wrote in message
news:bk******** **@newstree.wis e.edt.ericsson. se...

David White wrote:

Arrays and pointers have a whole bunch of properties.
I am sorry but I have no idea what do you mean.

They aren't any use if they don't have properties.

If an array is involved in a particular operation, then
particular behaviour will result, whether its name is used or not.

You have just said nothing.

No, I've said that one should not be preoccupied by an array's name.

As long as you know what will happen in a given circumstance,
then I don't see why you would think in terms of an array's
name, unless you happen to find it easier to remember
everything that way.

Because the rules are based on that. You could start to disregard traffic
lamps, because you think that instinct will drive you through the road
crossings better, but it is not a life insurance.

The rules might be stated that way. It doesn't mean that's the most
appropriate way to understand arrays. There are also declaration rules,
e.g., that the * in a pointer declaration is bound more closely to the
identifier than to the type. But that doesn't stop people, including the
designer of C++, writing char* p instead of char *p, in defiance of the
rules. I'm sure that at least some such people know the rules, but they
still prefer to think of them differently in that special case. Now, where
these people have chosen to make a special case out of a general rule, I've
chosen to make a general case out of arrays wherever the rules allow it,
regardless of the form in which the rules are expressed.
There is a simple trick to learn and understand the rules of arrays in C and C++. It goes like this: learn and understand the rules of arrays in C and
C++. Of course you can choose a separate route and not learn them, but then you will not know them.
Well, I don't know. I've been using arrays and pointers for a long time and
the way I think of them hasn't got me into trouble yet. I don't remember
ever being confused as to whether a reference to an array would be treated
as an array or a pointer.

If you list the exceptions and you miss one, the statement "An array
is treated as a pointer except..." becomes a false statement.

It is _always_ a false statement. And array is *never* treated as a
pointer. The *name* of the array *variable* can behave as or decay
into a pointer.

What about here?

void f(char *p)
{
}

void g()
{
char c[10];
char (*pc)[10] = &c;
f(*pc);
}

Isn't *pc an unnamed array?

Yes. But you are still referring to an array in an expression.

That was the whole idea - to demonstrate that the result is the same whether
you refer to an array by name or not.
reference takes the form of *pc or "My char array" it does not matter. It
is not the array which changes its type: only the way you refer to it
changes.
Yes, I know. I said as much in my very first post:
"If you use 'c' where a char * is expected, the compiler will create the
char * by taking the address of the first char in the array. But 'c' itself
is an array, not a pointer, so it is a different type from 'a' and 'b'."

The value of sizeof(*pc) suggests that it is.

I am not exactly sure if it is right to call that an unnamed array. An
unnamed array should be an array temporary, and AFAIK those do not exist,
since you are unable to return arrays from functions. The closest thing I
can imagine is that character literal above.

The argument *pc either is an array name or it isn't. I suggest that it
isn't. Are you saying that the term 'array name', or equivalent, as you've
used it under this topic so far, was intended to embrace expressions that
evaluate to arrays as well as actual names of arrays? Is this how the
standard defines an array's name?

So doesn't f(*pc) convert our unnamed array into a pointer to its
first element?

Not really. Not the array. The reference to it.

I am aware that an object cannot spontaneously change its type. See the
first-post quote above for the intended meaning.

The array is the object (the storage) with its type.
I'm aware of that. That's why I never think of arrays as pointers.

Good. Now the next step is to do it also the other way around.

So we just forget about that then?

OK. Forget. The *array* is *not* used either. Plain and simple. You

use a struct/class. The array type is used by the copy constructor or the
assignment operator of that class type. Very different situation.

Yes, different situation. Nevertheless, it is one circumstance in which an
array is not treated like a pointer. I'm not sure why this shouldn't counted
among the cases in which an array is not treated like a pointer.

This argument started when I questioned Kevin Goodsell's statement:
"If you use 'c' for any purpose other than as the operand for the address-of
or sizeof operator, the compiler will convert it to char*. It does not have
to occur in a context that calls for a char*."

Whatever Kevin meant by 'c', I've been talking about the array 'c' and its
like, not the name 'c'. I am yet to be convinced that a discussion of the
treatment of an array should be confined to the usage of its name. If there
is any circumstance in which the usage of an array's name causes different
behaviour than an expression that evaluates to an array (e.g., *pc above, if
that is indeed not a name), then of course it should be pointed out, but
where the behaviour is the same in both cases, it seems to me more useful to
describe that behaviour in terms of any expression that evaluates to an
array (according to the appropriate type declaration) rather than array
names. Why be specific if you can be general? And for completeness, there's
no reason to exclude the treatment of arrays in other contexts, such as in
class/struct default assignment.

I didn't think the OP was asking about names.
I thought the question was about pointers and arrays.

And I did not answer to the OP talking about names.

I didn't either, but somehow they keep coming up.

Default assignment of structs needs to be learned
as much as anything else.

There is no such thing in C++. structs are class types.

Have I got this right? You are saying that there is no such thing as structs
in C++, yet structs are class types in C++?

DW

[Default User]

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.


Brian Rodenborn

[Alexander Terekhov]

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

regards,
alexander.

[White Wolf]

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

For all I know I have asked you a question. If you cannot answer it just
say so. Nobody is perfect.

BTW your obsession with me is worrying. I state it second and last time for
you: I pay no special attention to you (unlike you to me) and I am not
interested in your paranoia. If you cannot answer a question just don't
post or post that.

--
WW aka Attila

[Default User]

Alexander Terekhov wrote:

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

I thought you and Wolfie was best buds, and you'd want to hear from him.


Brian Rodenborn

[White Wolf]

Default User wrote:

Alexander Terekhov wrote:

Default User wrote:

White Wolf wrote:

Really? How come? What do you mean by that?

Go troll somebody else. Al's always up for it.

Really? How come? What do you mean by that?

I thought you and Wolfie was best buds, and you'd want to hear from
him.

We are so much best buds that we have spent quite a considerable time
arguing and at that time I was indeed an asshole. :-) IIRC we have even
spent some time in each others killfile. But if people do not refuse to
think and listen to each other things work out.

--
WW aka Attila

[White Wolf]

White Wolf wrote:

We are so much best buds that we have spent quite a considerable time
arguing and at that time I was indeed an asshole. :-)

BTW me being an PITA at that time was due to my complete misunderstandin g of
thread and SMP related issues - amongst many other. :-)

--
WW aka Attila

[Default User]

White Wolf wrote:

BTW your obsession with me is worrying.

Go troll somebody else.

Brian Rodenborn