array

[buuuuuum]

why array can't be assigned, like structs?

[dwks]

On Mar 7, 10:26 pm, [e-mail] wrote:

why array can't be assigned, like structs?

Because an array can be passed to a function, or something, and the
compiler can not always know how big the array is. (This is the only
reason I can think of offhand, there are almost certainly others.)
Structures, on the other hand, always contain the same contents and so
the compiler can assign them.

Of course, if you want to assign one array to another, you can use the
memcpy() function (or memmove() if the parameters might overlap):

int array[] = {1, 2, 3, 4, 5};
int toarray[sizeof(array)/sizeof(*array)];

memcpy(toarray, array, sizeof(array));

[Keith Thompson]

"dwks" <ki**********@primus.cawrites:

On Mar 7, 10:26 pm, [e-mail] wrote:

>why array can't be assigned, like structs?

Because an array can be passed to a function, or something, and the
compiler can not always know how big the array is. (This is the only
reason I can think of offhand, there are almost certainly others.)
Structures, on the other hand, always contain the same contents and so
the compiler can assign them.

[...]

No, an array can't be passed to a function. You can do what *looks*
like passing an array to a function, but you're really just passing a
pointer to its first element.

Arrays aren't first-class objects in C. "First-class" isn't a
well-defined concept, but basically it means that there are things you
can do with other types that you can't do with arrays. There isn't
necessarily some fundamental reason why this is so (it isn't in some
other languages); it's just the way the language happens to be
designed, influenced by its predecessors B and BCPL.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Flash Gordon]

bu******@gmail.com wrote, On 08/03/07 05:26:

why array can't be assigned, like structs?

Because the language does not allow it.
--
Flash Gordon

[Richard Heathfield]

dwks said:

On Mar 7, 10:26 pm, [e-mail] wrote:

>why array can't be assigned, like structs?

Because an array can be passed to a function,

No, it can't.

or something, and the
compiler can not always know how big the array is.

The compiler knows /exactly/ how big the array is.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[SRR]

On Mar 8, 10:26 am, [e-mail] wrote:

why array can't be assigned, like structs?

Because its the way language has been designed!
Its a feature(or liability!) inherited from the langauage B, C's
predecessor.In B arrays are called Vectors
You dont have the concept of structures in B. They are concepts
developed by C and therefore Ritchie has allowed assignment of one
structure variable to the other.

[santosh]

[e-mail] wrote:

why array can't be assigned, like structs?

It probably because of the very close relationship between arrays and
pointers in C. Pointers can, and often do, point to arbitrarily sized
blocks of memory, which can't be assigned to one another by the
compiler.

In fact, in pre-ANSI C, even instances of structures could not be
automatically assigned to one another.

[buuuuuum]

On Mar 8, 4:20 am, Flash Gordon <[e-mail]:

[e-mail] wrote, On 08/03/07 05:26:

why array can't be assigned, like structs?

Because the language does not allow it.

and

Because its the way language has been designed!

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

It probably because of the very close relationship between arrays and
pointers in C. Pointers can, and often do, point to arbitrarily sized
blocks of memory, which can't be assigned to one another by the
compiler.

why? why pointer and arrays have this relationship? There is no need!
And why only arrays are like this, and structs, integers, chars are
not
im asking this because i can't find any good reason for this behavior,
since array is just another type of the language

(sorry about my english)

[Mark McIntyre]

On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

>On Mar 8, 4:20 am, Flash Gordon <[e-mail]:

>[e-mail] wrote, On 08/03/07 05:26:

why array can't be assigned, like structs?

Because the language does not allow it.

and

Because its the way language has been designed!

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

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

>im asking this because i can't find any good reason for this behavior,
since array is just another type of the language

Not in C.
--
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

[Joe Wright]

santosh wrote:

[e-mail] wrote:

>why array can't be assigned, like structs?

It probably because of the very close relationship between arrays and
pointers in C. Pointers can, and often do, point to arbitrarily sized
blocks of memory, which can't be assigned to one another by the
compiler.

In fact, in pre-ANSI C, even instances of structures could not be
automatically assigned to one another.

K&R1 was published in 1978. In that book BWK notes that DMR's compiler
implemented struct assignment. There was no Standard of course until
1989 and K&R1 does not describe it as part of C.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

>>On Mar 8, 4:20 am, Flash Gordon <[e-mail]:

>>[e-mail] wrote, On 08/03/07 05:26:

why array can't be assigned, like structs?

Because the language does not allow it.

and

>Because its the way language has been designed!

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

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

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

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

bu******@gmail.com writes:

On Mar 8, 4:20 am, Flash Gordon <[e-mail]:

>[e-mail] wrote, On 08/03/07 05:26:

why array can't be assigned, like structs?

Because the language does not allow it.

and

Because its the way language has been designed!

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

[...]

Because it's difficult, in terms of language design, to support array
assignment and make it correct and useful.

Structure assignment is relatively easy. All structures of a given
type have the same size, so assignment can just copy the entire
content of the structure to the target object.

On the other hand, you can have arrays of different numbers of the
same element type. For example:

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

If you wanted to support array assignment, you could just say that a3
and a5 have different types and can't be assigned. Or you could allow
a subset of an array to be copied to a subset of another, but that
requires inventing a syntax to specify a subset of an array, something
C doesn't have. But it's also important to be able to deal with
dynamically allocated arrays, preferably using the same syntax. This
introduces the possibility of writing an array assignment where the
source and target lengths don't match, but the mismatch can't be
detected until run time. Now you have to decide what to do if the
lengths don't match. Do you copy just part of the array, ignoring the
excess? Or do you define some way of detecting the error at run time;
if so, should it terminate the program, or should there be a way to
recover after the fact? Now you need an exception handling mechanism,
something that few if any languages had when C was first being
designed. Or do you just say that a length mismatch causes undefined
behavior, introducing an incredibly rich new source of program bugs?

C's array semantics are relatively simple, and almost elegant in an
uncomfortably-close-to-the-hardware kind of way. By using pointers
(or, equivalently, array indexing), you can do anything with C arrays
that you can do with "real" arrays in any other language. You can
assign arrays using memcpy(), for example (and if the language
directly supported array assignment, the compiler would likely do the
equivalent of a memcpy() call anyway). It requires more work for the
programmer, but it also allows finer-grained control and flexibility.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

bu******@gmail.com wrote:

why array can't be assigned, like structs?

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

typedef struct array10 Array10;
struct array10 {
int data[10];
};

int main(void)
{
Array10 first = {{1,2,3,4,5,6,7,8,9,10}};

Array10 second = first;

return 0;
}

--
Ian Collins.

[Ben Pfaff]

Keith Thompson <ks***@mib.orgwrites:

Mark McIntyre <ma**********@spamcop.netwrites:

>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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Keith Thompson]

Ben Pfaff <bl*@cs.stanford.eduwrites:

Keith Thompson <ks***@mib.orgwrites:

>Mark McIntyre <ma**********@spamcop.netwrites:

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

An array type, such as int[4], is a derived type, and is a type.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[santosh]

Ian Collins wrote:

bu******@gmail.com wrote:

why array can't be assigned, like structs?

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

typedef struct array10 Array10;
struct array10 {
int data[10];
};

int main(void)
{
Array10 first = {{1,2,3,4,5,6,7,8,9,10}};

Array10 second = first;

return 0;
}

But if you find yourself doing this just for the sake of copying
arrays, you might be better of redesigning your program.

[Ian Collins]

santosh wrote:

Ian Collins wrote:

>>bu******@gmail.com wrote:

>>>why array can't be assigned, like structs?

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

typedef struct array10 Array10;
struct array10 {
int data[10];
};

int main(void)
{
Array10 first = {{1,2,3,4,5,6,7,8,9,10}};

Array10 second = first;

return 0;
}

But if you find yourself doing this just for the sake of copying
arrays, you might be better of redesigning your program.

Exactly, it shows the price you have to pay for a feature. To be able
to copy an array, the compiler has to know its size. The only way to
know the size is to make the arrays unique fixed size objects and
sacrifice all the simplicity and elegance of C's arrays.

--
Ian Collins.

[buuuuuum]

If you wanted to support array assignment, you could just say that a3

and a5 have different types and can't be assigned. Or you could allow
a subset of an array to be copied to a subset of another, but that
requires inventing a syntax to specify a subset of an array, something
C doesn't have.

yes,

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

are different type, so, cant be assigned

But it's also important to be able to deal with
dynamically allocated arrays, preferably using the same syntax. This
introduces the possibility of writing an array assignment where the
source and target lengths don't match, but the mismatch can't be
detected until run time.

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?

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

typedef struct array10 Array10;
struct array10 {
int data[10];

};

int main(void)
{
Array10 first = {{1,2,3,4,5,6,7,8,9,10}};

Array10 second = first;

return 0;

}

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

sacrifice all the simplicity and elegance of C's arrays.

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

[Keith Thompson]

bu******@gmail.com writes:

>If you wanted to support array assignment, you could just say that a3
and a5 have different types and can't be assigned. Or you could allow
a subset of an array to be copied to a subset of another, but that
requires inventing a syntax to specify a subset of an array, something
C doesn't have.

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

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.

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.

>But it's also important to be able to deal with
dynamically allocated arrays, preferably using the same syntax. This
introduces the possibility of writing an array assignment where the
source and target lengths don't match, but the mismatch can't be
detected until run time.

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.

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

>sacrifice all the simplicity and elegance of C's arrays.

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?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Thomas.Chang]

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

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

[Keith Thompson]

"Thomas.Chang" <Mi***********@gmail.comwrites:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Dollin]

Thomas.Chang wrote:

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.

--
Chris "electric hedgehog" Dollin
"What I don't understand is this ..." Trevor Chaplin, /The Beiderbeck Affair/

[Mark McIntyre]

On Thu, 08 Mar 2007 16:12:36 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

>On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

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.

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]

On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Ben Pfaff <bl*@cs.stanford.eduwrites:

>Keith Thompson <ks***@mib.orgwrites:

>>Mark McIntyre <ma**********@spamcop.netwrites:
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]

Mark McIntyre wrote:

On Thu, 08 Mar 2007 16:12:36 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

>>On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

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.

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]

On Fri, 09 Mar 2007 23:21:27 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Mark McIntyre wrote:

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

ss = {4, 5};

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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Mark McIntyre wrote:

On Fri, 09 Mar 2007 23:21:27 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

Mark McIntyre wrote:

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

ss = {4, 5};

struct Foo a, b;
a = b;

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.

Try this with arrays.

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.

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.

Your point is incorrect.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Harald van Dijk wrote:
[...]

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

As /an/ assignment operator.

[Yevgen Muntyan]

Mark McIntyre wrote:

On Fri, 09 Mar 2007 23:21:27 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>Mark McIntyre wrote:

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

ss = {4, 5};

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.

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.

>Try this with arrays.

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.

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

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]

Mark McIntyre <ma**********@spamcop.netwrites:

On Thu, 08 Mar 2007 16:12:36 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>Mark McIntyre <ma**********@spamcop.netwrites:

>>On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

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.

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 (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>Ben Pfaff <bl*@cs.stanford.eduwrites:

>>Keith Thompson <ks***@mib.orgwrites:

Mark McIntyre <ma**********@spamcop.netwrites:
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 (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.netwrites:

On Fri, 09 Mar 2007 23:21:27 GMT, in comp.lang.c , Yevgen Muntyan
<mu****************@tamu.eduwrote:

>>Mark McIntyre wrote:

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

ss = {4, 5};

struct Foo a, b;
a = b;

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?

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

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[buuuuuum]

On Mar 9, 12:07 am, Keith Thompson <[e-mail]:

[e-mail] writes:

If you wanted to support array assignment, you could just say that a3
and a5 have different types and can't be assigned. Or you could allow
a subset of an array to be copied to a subset of another, but that
requires inventing a syntax to specify a subset of an array, something
C doesn't have.

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

But it's also important to be able to deal with
dynamically allocated arrays, preferably using the same syntax. This
introduces the possibility of writing an array assignment where the
source and target lengths don't match, but the mismatch can't be
detected until run time.

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.

sacrifice all the simplicity and elegance of C's arrays.

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]

bu******@gmail.com writes:

On Mar 9, 12:07 am, Keith Thompson <[e-mail]:

>[e-mail] 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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Default User]

bu******@gmail.com wrote:

im sorry
im not familiar with newsgroups yet

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


Brian

[Richard Heathfield]

Default User said:

bu******@gmail.com wrote:

>im sorry
im not familiar with newsgroups yet

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

What would Google know about newsgroups?

Furrfu.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Default User]

Richard Heathfield wrote:

Default User said:

bu******@gmail.com wrote:

im sorry
im not familiar with newsgroups yet

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

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:

Richard Heathfield wrote:

>Default User said:

bu******@gmail.com wrote:
im sorry
im not familiar with newsgroups yet
<http://groups.google.com/support/bin/topic.py?topic=9246>

What would Google know about newsgroups?

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On 9 Mar 2007 16:03:04 -0800, in comp.lang.c , "Harald van D?k"
<tr*****@gmail.comwrote:

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

***********

>Mark McIntyre <ma**********@spamcop.netwrites:

>On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , bu******@gmail.com
wrote:

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

***********

(snippage)

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

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.

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

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]

On Fri, 09 Mar 2007 17:04:54 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>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

[Mark McIntyre]

On Fri, 09 Mar 2007 17:05:49 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

>On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

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

My original statement was absolutely correct, An array is a derived
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

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

On Mar 10, 12:05 pm, Mark McIntyre <[e-mail]:

On 9 Mar 2007 16:03:04 -0800, in comp.lang.c , "Harald van D?k"
<[e-mail]:

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.

***********>Mark McIntyre <[e-mail]:

On 8 Mar 2007 11:01:30 -0800, in comp.lang.c , [e-mail]
wrote:

[un-snip start]

why? what's the reason? why array's cant be like any other type in C?
why it have to be different?

[un-snip end]

>

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

***********

You snipped too much. You claimed that an array isn't a type, and that
that is the reason it has to be different. If others don't read your
reply as an answer to the question (as "Because an array isn't a
type.") though, I'll admit I'm wrong on that part.

(snippage)

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

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

And I showed that you /can/ assign to a struct using that same method.
The syntax is different from initialisation, but I also showed that
the syntax for initialising and assigning to basic types
(specifically, int) differs as well, so how did you read that as a
difference between structures and basic types?

[Default User]

Richard Heathfield wrote:

Default User said:

Richard Heathfield wrote:

Default User said:

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

What would Google know about newsgroups?

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.

Did you actually READ the link I provided?

"What is a Usenet Newsgroup?

Usenet is an online bulletin board system that began at Duke University
in 1979. Usenet users can post messages to newsgroups that can be read
(and responded to) by anyone who has access to the system through a
newsreader. Over the years, the number of newsgroups has grown into the
thousands, hosted all over the world and covering every conceivable
topic.

Google Groups contains the world's most comprehensive archive of Usenet
postings, dating back to 1981. Google Groups eliminates the need for a
newsreader and lets you search this archive the same way you'd search
on the web. You can also use Google Groups to post your own comments to
an existing Usenet newsgroup."

Nor will he learn that Google behaves irresponsibly by refusing to
clamp down on Usenet abuse perpetrated via their servers.

That's a different story.

Brian

[Ben Pfaff]

Mark McIntyre <ma**********@spamcop.netwrites:

On Fri, 09 Mar 2007 17:05:49 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

>>Mark McIntyre <ma**********@spamcop.netwrites:

>>On Thu, 08 Mar 2007 17:31:40 -0800, in comp.lang.c , Keith Thompson
<ks***@mib.orgwrote:

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

My original statement was absolutely correct, An array is a derived
type.

That part of your original statement, in the second sentence, was
correct (except for the grammatical error of "its"). The problem
was with the first sentence. Here, let me present it again:

Mark McIntyre <ma**********@spamcop.netwrites:

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

--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless

[Mark McIntyre]

On 10 Mar 2007 08:10:53 -0800, in comp.lang.c , "Harald van D?k"
<tr*****@gmail.comwrote:

>You snipped too much. You claimed that an array isn't a type, and that
that is the reason it has to be different.

You apparently mentally snipped too much, for the distinction I was
drawing was between a simple and derived type.

>And I showed that you /can/ assign to a struct using that same method.

So what? As I've said ad nauseam, you can't prove it by example, only
disprove by counterexample.

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

On Sat, 10 Mar 2007 09:25:20 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:

>That part of your original statement, in the second sentence, was
correct (except for the grammatical error of "its"). The problem
was with the first sentence. Here, let me present it again:

Feel free, I've done so myself elsethread.

>Mark McIntyre <ma**********@spamcop.netwrites:

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

Clearly people are harder of reading than I thought. The distinction
I'm making is between a simple and derived 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

[Richard Heathfield]

Default User said:

Richard Heathfield wrote:

>Default User said:

Richard Heathfield wrote:
Default User said:

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

What would Google know about newsgroups?

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.

Did you actually READ the link I provided?

Yes, actually. Hence "might not" rather than "will not".

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Heathfield]

Mark McIntyre said:

On Sat, 10 Mar 2007 09:25:20 -0800, in comp.lang.c , Ben Pfaff
<bl*@cs.stanford.eduwrote:

>>That part of your original statement, in the second sentence, was
correct (except for the grammatical error of "its"). The problem
was with the first sentence. Here, let me present it again:

Feel free, I've done so myself elsethread.

>>Mark McIntyre <ma**********@spamcop.netwrites:

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

Clearly people are harder of reading than I thought. The distinction
I'm making is between a simple and derived type.

Nevertheless, the way in which you drew that distinction is flawed, and
that's all that your correspondents seem to be claiming.

If an array is a derived type, then it is a type, and yet you claimed:
"An array isn't a type." Clearly, you understand that it /is/ in fact a
type, so presumably you will understand and agree that the sentence I
just quoted is incorrect.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ben Pfaff]

Mark McIntyre <ma**********@spamcop.netwrites:

>>Mark McIntyre <ma**********@spamcop.netwrites:

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

Clearly people are harder of reading than I thought. The distinction
I'm making is between a simple and derived type.

OK. In the future please try to make it clear by saying "An
array isn't a simple type" then.
--
"...Almost makes you wonder why Heisenberg didn't include postinc/dec operators
in the uncertainty principle. Which of course makes the above equivalent to
Schrodinger's pointer..."
--Anthony McDonald

[Yevgen Muntyan]

Mark McIntyre wrote:

On 10 Mar 2007 08:10:53 -0800, in comp.lang.c , "Harald van D?k"
<tr*****@gmail.comwrote:

>You snipped too much. You claimed that an array isn't a type, and that
that is the reason it has to be different.

You apparently mentally snipped too much, for the distinction I was
drawing was between a simple and derived type.

>And I showed that you /can/ assign to a struct using that same method.

So what? As I've said ad nauseam, you can't prove it by example, only
disprove by counterexample.

You mean you can't prove that assignment is possible by providing
an example of assignment; but it's possible to disprove it by providing
piece of code which isn't even C? Interesting. What does "one can
assign structures" in your world? You really need to state what you
are "proving".

Yevgen