Attila Feher said:
I am sorry but I have no idea what do you mean.
They aren't any use if they don't have properties.
You have just said nothing.
No, I've said that one should not be preoccupied by an array's name.
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'."
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?
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.
Good. Now the next step is to do it also the other way around.
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.
And I did not answer to the OP talking about names.
I didn't either, but somehow they keep coming up.
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
IIRC we have even