In C, a struct
(record data structure) can be the return type of a function, but an array cannot be. What design characteristics of the C Language cause arrays to b
The characteristic is that in the small and speedy C language you don't want the equivalent of large memcpy
operations when returning. If you badly need arrays returned, make them a member of a struct
, and voila, array return in C. Sort of, starting with C89 :-)
Or use a memcpy
yourself when and where you need it.
Most obviously, the "lack" is that C doesn't permit a function to return a result of an array type. This is stated explicitly in the language standard.
Array types are, in a sense, second-class citizens in C. In most contexts, an expression of array type is implicitly converted to a pointer to its first element. The exceptions are when the array expression is the operand of sizeof
(which yields the size of the array), when it's the operand of unary &
(which yields the address of the array), and when it's a string literal in an initializer used to initialize an array object.
This absolutely does not mean that arrays are "really" pointers; they're not. You'll see people claiming that they are. They're wrong.
Functions return values. You can have a value of a structure type; that value consists of the values of its members. C permits assignment, parameter passing, and function results of structure type. All these manipulate array values (they deal with them by value, not by reference).
The same is not true for arrays. The rules I mentioned above imply that you can't construct an expression whose value is of an array type. There are array values (consisting of the values of all the array's elements), but such values are difficult or impossible to manipulate directly.
The way C code usually manipulates arrays is by using pointers to individual elements.
It probably wouldn't have been too difficult to have designed C so that fixed-size arrays can be treated as values, with assignment, parameter passing, and so forth. But then you'd run into problems where int[10]
and int[11]
are two distinct and incompatible types. Most C code that deals with arrays needs to handle arrays whose size is determined at run time. For example, the string functions in <string.h>
deal with arrays of characters of any arbitrary length. They do so by using pointers to the elements of the arrays. You couldn't very well have distinct functions for 1-element, 2-element, 3-element, and so forth, arrays.
You can do the equivalent of returning an array value from a function, but it's unfortunately awkward. You can return a structure containing the array -- but then the size of the array has to be fixed at compile time. You can return a pointer to (the first element of) the array -- but then you have to deal with allocating and deallocating memory to hold the array. You can have the caller pass in a pointer to an array -- but that places the burden of memory management on the caller. And so forth.
Yes, it's all a bit of a mess. But dealing with arrays that can vary in size is genuinely difficult. C gives you all the tools you need to do it, but leaves a lot of the detailed management to you, the programmer. (Other languages provide arrays as first-class types. Many of those languages have compilers or interpreters written in C.)
Suggested reading: Section 6 of the comp.lang.c FAQ.
A naked array type in C language is not copyable for primarily historical reasons. For this reason it is not possible to initialize arrays with arrays, assign arrays to arrays, pass arrays by value as parameters or return arrays from functions. (Initialization context has a notable exception of char s[6] = "Hello";
.)
It is still possible to do all the above if the array is wrapped in struct type, which demonstrates that the limitation is purely declarative in nature. There's no compelling technical reason for it.
C language inherited its approach to array implementation from its historical predecessors - B and BCPL languages. In B/BCPL arrays were openly implemented as pointers, meaning that an attempt to assign one array to another actually represented assignment of pointers. C language followed a different approach. In C arrays are not pointers, but the interface specification of C arrays is kept superficially compatible with that of B/BCPL. Arrays in C still "pretend" to be pointers in most contexts. This is one reason they are not immediately copyable.
While the array can't be returned from a C function, a pointer to the array may. For code example of how to do what you're looking for, visit the site:
http://www.tutorialspoint.com/cprogramming/c_return_arrays_from_function.htm