array

[Keith Thompson]

array name is a constant pointer to a consecutive memory
it feels strange to assign one array to another

Please provide context when you post a followup.
See <http://cfaj.freeshell.org/google/>.

An array name is *converted* to a pointer to its first element in
most, but not all, contexts. See section 6 of the comp.lang.c FAQ for
details.

 

[Chris Dollin]

array name is a constant pointer to a consecutive memory

No more so than the name of any other variable. What happens in
/value context/ is different, though.

it feels strange to assign one array to another

No more so than for any other variable.

something off the topic: the design are all human-made, which has its
historical reasons, so may be occasional and unreasonable.

True.

The problem for C is that we're mostly not dealing with arrays, but
with pointers to elements inside arrays. This makes lots of things
simple and elegant, but getting at the size of the underlying array
isn't one of them. Trying to fix this would likely have performance
penalties inappropriate to the current uses of C.

 

[Mark McIntyre]

No, an array type, like any derived type, is a type.

Yes, its a derived type. Your disagreement is senseless by the way.

For example,
"int[4]" is a type, "array of 4 ints".

Both array types and structure types are derived types; assignment is
defined for structure types, but not for array types.

Really? Can you say , given some suitable definition of a struct with
two integer members

ss = {4, 5};

?

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

An array isn't a type. Its a derived type, and has different
behaviour. Similarly structs.

No, an array type, like any derived type, is a type. For example,
"int[4]" is a type, "array of 4 ints".

I thought about responding similarly to Mark's article, but then
it occurred to me that, in fact, "array" isn't a type in the same
sense that, say, "int" is a type. "Array of int" (e.g.) is an
(incomplete) type, but "array" isn't really a type; it's more of
a declarator, to adopt name from the Standard's syntax
productions.

Good point, though I don't know whether that's what Mark meant (note
that he said "an array", not "array".

It would have been clearer if I'd said "an array is not a simple
type".


--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Yevgen Muntyan]

Yes, its a derived type. Your disagreement is senseless by the way.

It makes perfect sense.

For example,
"int[4]" is a type, "array of 4 ints".

Both array types and structure types are derived types; assignment is
defined for structure types, but not for array types.

Really? Can you say , given some suitable definition of a struct with
two integer members

ss = {4, 5};

struct Foo a, b;
a = b;

Try this with arrays. You really don't see what it's all about?

Yevgen

 

[Mark McIntyre]

struct Foo a, b;
a = b;

Nit: some would say you're copying here, not assigning....
Nit2: an example isn't a proof, whereas a counterexample is a
disproof. I've a feeling we've had this conversaton before.

Try this with arrays.

I'm curious as to how that answers my question above.

You really don't see what it's all about?

Of course I do. The point I'm making is that derived types have
different semantics for assignment.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Guest]

Nit: some would say you're copying here, not assigning....

The standard refers to the = operator as the assignment operator.

Nit2: an example isn't a proof, whereas a counterexample is a
disproof. I've a feeling we've had this conversaton before.

You claimed that array assignment /has/ to be disallowed, because
arrays are derived types. Yevgen Muntyan's example disproved this.

I'm curious as to how that answers my question above.

It doesn't, because your question was not relevant, and one logical
conclusion was that you might be misunderstanding the issue.
Assignment requires an lvalue, and assignment operator, and an
expression. You have an lvalue, an assignment operator, and an
initialiser list. You need to create an expression from your
initialiser list. There is not much special about structures here:

int a = { 0 }; is valid.

int a;
a = { 0 }; is invalid.

int a;
a = 0; is valid.

struct S s = { 0 }; is valid.

struct S s;
s = { 0 }; is invalid.

struct S s;
s = (struct S) { 0 }; is valid.

Of course I do. The point I'm making is that derived types have
different semantics for assignment.

Your point is incorrect.

 

[Guest]

Harald van Dijk wrote:
[...]

The standard refers to the = operator as the assignment operator.

As /an/ assignment operator.

 

[Yevgen Muntyan]

Nit: some would say you're copying here, not assigning....
Nit2: an example isn't a proof, whereas a counterexample is a
disproof. I've a feeling we've had this conversaton before.

Oh yeah. You like to provide such "counterexamples" which don't
prove anything (since they are not relevant to discussed issue).

My example was an example of structure assignment which you
claim is impossible. You were also proposed to try assignment
with arrays to see what the *original* question was about.

I'm curious as to how that answers my question above.

Your question above wasn't about assignment, it was a different
thing: why doesn't C allow your code. It's a good question, but
it's not relevant to the original question about assignment.

Of course I do. The point I'm making is that derived types have
different semantics for assignment.

While it's true, it's irrelevant. The original question was
"why array can't be assigned, like structs?". Your point
seems to be "because they are derived types", but it clearly
false for structures, so can't be true as it is, in all
its generality.

Yevgen

 

[Keith Thompson]

Yes, its a derived type. Your disagreement is senseless by the way.

You said an array is not a type. In fact, an array is a type. More
precisely, an array type is a type. I assumed that by "an array", you
meant "an array type"; if you meant something else, please clarify.

I disagreed because you made a false statement. I see nothing
"senseless" about that.

I suspect that you *meant* something different, but I'm not going to
guess what it might have been; I can only respond to what you actually
write.

For example,
"int[4]" is a type, "array of 4 ints".

Both array types and structure types are derived types; assignment is
defined for structure types, but not for array types.

Really?

Yes, really.

Can you say , given some suitable definition of a struct with
two integer members

ss = {4, 5};

?

No, because {4, 5} is not an expression of a struct type. That has
nothing to do with whether assignment is defined for structure types.
It is defined.

Try this:

#include <stdio.h>
int main(void)
{
struct foo { int x; int y; };
struct foo obj1 = { 4, 5 };
/*
* { 4, 5 } is a valid initializer, though it's not a valid
* expression
*/
struct foo obj2;

obj2 = obj1;
/*
* The above statement is an assignment.
* Now let's verify that it worked.
*/

printf("obj2.x = %d, obj2.y = %d\n", obj2.x, obj2.y);
return 0;
}

My suspicion is that this program doesn't tell you anything you don't
already know perfectly well.

Mark, you could save us all a great deal of time and trouble if, every
now and then, you'd just admit when you've made a mistake. Instead,
when you make a sloppy and incorrect statement (which we all do now
and then), you respond to corrections by insisting that you were right
and it's our fault for not understanding you. It's tiresome.

 

[Keith Thompson]

An array isn't a type. Its a derived type, and has different
behaviour. Similarly structs.

No, an array type, like any derived type, is a type. For example,
"int[4]" is a type, "array of 4 ints".

I thought about responding similarly to Mark's article, but then
it occurred to me that, in fact, "array" isn't a type in the same
sense that, say, "int" is a type. "Array of int" (e.g.) is an
(incomplete) type, but "array" isn't really a type; it's more of
a declarator, to adopt name from the Standard's syntax
productions.

Good point, though I don't know whether that's what Mark meant (note
that he said "an array", not "array".

It would have been clearer if I'd said "an array is not a simple
type".

Yes, it would have been clearer. It would also have been correct,
which your original statement quite simply was not.

 

[Keith Thompson]

Nit: some would say you're copying here, not assigning....

It's an assignment, specifically a simple assignment. The effect of
an assignment is to copy a value. Your "nit" is senseless.

Nit2: an example isn't a proof, whereas a counterexample is a
disproof. I've a feeling we've had this conversaton before.

A counterexample of what?

Suppose ss is of an arithmetic type. Can you give some suitable
definition such that

ss = { 42 };

is a valid assignment? If not, what exactly does that prove or
disprove?

I'm curious as to how that answers my question above.


Of course I do. The point I'm making is that derived types have
different semantics for assignment.

Different *types* have different semantics for assignment. The
distinction between derived types and non-derived types is not
relevant. Specifically:

The arithmetic types (integer, floating, and complex) are not
derived types. Assignment is defined for all of them.

void is not a derived type. Assignment is not defined for type
void.

Array types are derived types. Assignment is not defined for
array types.

Structure and union types are derived types. Simple assignment is
defined for them, just as it is for the arithmetic types.

Function types are derived types. No assignment.

Pointer types are derived types. Pointer and arithmetic types
collectively are called scalar types; assignemnt is defined for
them.

There is no correlation between whether a type is derived, and whether
assignment is defined for it.

Stop digging.

 

[buuuuuum]

I wrote the above, starting with "If you wanted ...". Please don't
snip attribution lines.

im sorry
im not familiar with newsgroups yet

yes,

int a3[3];
int a5[5];

are different type, so, cant be assigned

It sounds like you're suggesting allowing assignment for arrays, but
only when both arrays have the same constant length. If you wanted,
for example, to copy just the first three elements of a5 into a3, or
copy all of a3 into the first three elements of a5, then your proposed
array assignment operation couldn't be used. I suppose you could do
something with pointer conversions, but the result would be more
difficult to read than the equivalent memcpy() call.

like i said, you could write '&array[0]' instead 'array'

In my opinion, an array assignment operation that works only on
matching constant-length array objects is too limited to be
particularly useful, and one that's sufficiently general to be useful
(working on dynamic arrays, for example) would require too much
additional infrastructure to be practical *as an addition to C*. As I
wrote before, the existing C constructs give you all the flexibility
you could want, at the cost of some loss of convenience.

i think in arrays just like structs

struct somestruct {
char name[50];
int age;
...
char address[50];
};

struct similartosomestruct {
char name[50];
int age;
...
char address[50];

char sex;
};

they are very similar, but not assignable

are you talking about:

int *ptr=malloc(sizeof(int) * 10);

where ptr is a pointer

or

int (*ptr)[10];

where we know the array size?

The former, mostly. The malloc() call effectively creates an array of
10 ints; ptr points to the first of them, but doesn't include any
information about the size of the array. The second declaration makes
ptr a pointer to an array of exactly 10 ints; this is rarely useful
because it's so inflexible.

but, ptr is not an array, its a pointer to int, how can we write an
array assingment with this pointer?

If you want to be able to copy arrays, put them in a struct and copy the
structs.

[snip]
its simple, isn't?
so, why arrays can't do this?

Because that's the way the language is designed.

yes, and that is my question.

if arrays were assignable you still could write &array[0], isn't it
the same thing?

Sure, if arrays were assignable, the implicit conversion of an array
name to a pointer would have to be modified. I'm not sure *how* it
would have to be modified. Getting rid of it altogether would require
other changes to the language. Any such change would almost
inevitably break existing code, and that's just not going to happen.

How often do you really need to assign arrays, anyway? There are
certainly times when copying an array can be useful, but in many cases
it's more useful just to copy pointers around.

Can you provide a realistic example of a program that would be
significantly easier to write if arrays were assignable?

i think the main thing that would change is to change 'array' by
'&array[0]',

im not asking for changes on the language, of course, its just a
question, why arrays are like this, i think there is no need
for me, would be much more simple and with sense if array were
assignable
so they could be passed and returned by function too, just like structs

 

[Keith Thompson]

(e-mail address removed) writes: [big snip]

If you want to be able to copy arrays, put them in a struct and copy the
structs. [snip]
its simple, isn't?
so, why arrays can't do this?

Because that's the way the language is designed.

yes, and that is my question.

And I've answered it about as well as I can.

 

[Default User]

im sorry
im not familiar with newsgroups yet

<http://groups.google.com/support/bin/topic.py?topic=9246>




Brian

 

[Richard Heathfield]

Default User said:

<http://groups.google.com/support/bin/topic.py?topic=9246>

What would Google know about newsgroups?

Furrfu.

 

[Default User]

Default User said:


What would Google know about newsgroups?

He's a Google user, he ought to be at least familiar with their help
section.




Brian

 

[Richard Heathfield]

Default User said:

He's a Google user, he ought to be at least familiar with their help
section.

Yeah. What he might not realise from reading Google's help pages is that
newsgroups are not a Google product, but a well-established on-line
society to which Google has attached itself like a remora. Nor will he
learn that Google behaves irresponsibly by refusing to clamp down on
Usenet abuse perpetrated via their servers.

 

[Mark McIntyre]

You claimed that array assignment /has/ to be disallowed, because
arrays are derived types. Yevgen Muntyan's example disproved this.

No I didn't. I said that an array was a derived type, not a simple
type and has different behaviour.

***********

***********

(snippage)

It doesn't, because your question was not relevant,

My point was that derived types have different behaviour to simple
types, and so you cannot assume that simple assignment will be
possible. I gave an example showing how you cannot assign to a struct
using a method that other languages support, and indeed C allows you
to use to /initialise/ a struct (and indeed an array).

Assignment requires an lvalue, and assignment operator, and an
expression. You have an lvalue, an assignment operator, and an
initialiser list.

This is a post-facto argument, and also merely a repetition of what I
said couched in standardese.

Your point is incorrect.

Oh? So you think that derived types have the same semantics, despite
evidence you yourself have produced to the contrary...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Mark McIntyre]

Mark, you could save us all a great deal of time and trouble if, every
now and then, you'd just admit when you've made a mistake.

I would, if I thought I had. I don't think I have.

Instead,
when you make a sloppy and incorrect statement (which we all do now
and then), you respond to corrections by insisting that you were right
and it's our fault for not understanding you.

I resent the implications of that. When I am wrong, I admit it.

On the other hand when I think I'm right, or that people are arguing
with me foolishly, I am not prepared to go quietly into the night.

It's tiresome.

Thats a shame for you but hardly my problem. If you don't like my
style, you have no obligation to read my posts.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan