array

[buuuuuum]

why array can't be assigned, like structs?

 

[dwks]

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

 

[Flash Gordon]

why array can't be assigned, like structs?

Because the language does not allow it.

 

[Keith Thompson]

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.

 

[Richard Heathfield]

dwks said:

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.

 

[SRR]

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]

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]

(e-mail address removed) wrote, On 08/03/07 05:26:


Because the language does not allow it.
and

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

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]

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]

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.

 

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

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

 

[Keith Thompson]

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.

 

[Ben Pfaff]

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.

 

[Ian Collins]

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;
}

 

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

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

 

[santosh]

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]

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.

 

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

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?

 

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