Some languages enable you to just declare a function returning an array like a normal function, like Java:
public String[] funcarray() {
String[] test = new String[]{"hi", "hello"};
return test;
}
Why doesn't C++ support something like int[] funcarray(){}
?
You can return an array, but it's a real hassle to make such a function. And also, I heard somewhere that strings are just arrays of char. So if you can return a string in C++, why not an array?
Check out here. Really helpful.
C++ does support it - well sort of:
Even C sort-of supports it:
A
std::string
is a class but when you say a string you probably mean a literal. You can return a literal safely from a function but actually you could statically create any array and return it from a function. This would be thread-safe if it was a const (read-only) array which is the case with string literals.The array you return would degrade to a pointer though, so you would not be able to work out its size just from its return.
Returning an array, if it were possible, would have to be fixed length in the first place, given that the compiler needs to create the call stack, and then has the issue that arrays are not l-values so receiving it in the calling function would have to use a new variable with initialisation, which is impractical. Returning one may be impractical too for the same reason, atlhough they might have used a special notation for return values.
Remember in the early days of C all the variables had to be declared at the top of the function and you couldn't just declare at first use. Thus it was infeasible at the time.
They gave the workaround of putting the array into a struct and that is just how it now has to remain in C++ because it uses the same calling convention.
Note: In languages like Java, an array is a class. You create one with new. You can reassign them (they are l-values).
Return a
std::vector<>
instead of an array. In general, arrays do not work well with C++, and should generally be avoided.Also, the
string
datatype is not just an array of characters, although a "quoted string" is. Thestring
manages an array of characters, and you can get access to it with.c_str()
, but there's more to astring
than that.From a discussion here:
http://forum.codecall.net/c-c/32457-function-return-array-c.html
Arrays in C (and in C++ for backwards compatibility) have special semantics that differ from the rest of the types. In particular, while for the rest of the types, C only has pass-by-value semantics, in the case of arrays the effect of the pass-by-value syntax simulates pass-by-reference in a strange way:
In a function signature, an argument of type array of N elements of type T gets converted to pointer to T. In a function call passing an array as argument to a function will decay the array to a pointer to the first element, and that pointer is copied into the function.
Because of this particular treatment for arrays --they cannot be passed by value--, they cannot be returned by value either. In C you can return a pointer, and in C++ you can also return a reference, but the array itself cannot be allocated in the stack.
If you think of it, this is not different from the language that you are using in the question, as the array is dynamically allocated and you are only returning a pointer/reference to it.
The C++ language, on the other hand, enables different solutions to that particular problem, like using
std::vector
in the current standard (contents are dynamically allocated) orstd::array
in the upcoming standard (contents can be allocated in the stack, but it might have a greater cost, as each element will have to be copied in those cases where the copy cannot be elided by the compiler). In fact, you can use the same type of approach with the current standard by using off-the-shelf libraries likeboost::array
.Other have said that in C++, one use vector<> instead of the arrays inherited from C.
So why C++ doesn't allows to returns C arrays? Because C doesn't.
Why C doesn't? Because C evolved from B, a untyped language in which returning an array doesn't make sense at all. When adding types to B, it would have been meaningful to make it possible to return an array but that wasn't done in order to keep some B idioms valid and ease the conversion of programs from B to C. And since then, the possibility of making C arrays more usable as always been refused (and even more, not even considered) as it would break too much existing code.