grumpy

Dawei is quite correct. It is a common beginners mistake to believe that using low level features of C (eg arrays) is a good way to achieve "efficiency". In my experience, most people who advocate doing something for "efficiency" rarely give any objective measure of that "efficiency" and almost never offer a convincing argument that the approach they encourage is actually more "efficient" than an alternative. And, in fact, the approach they advocate is often a poor one.

As I said in another thread (linked to by jayme above), there are several techniques for returning an array from a function. All of them have trade-offs.

In practice, in C++, if you want a collection of objects, the standard container classes (vector, list, etc) are measurably better than alternatives in several ways;

1) They are (apart from bugs in compilers and their libraries, which are relatively rare) guaranteed to work in all reasonably modern C++ compilers and operating systems because their behaviour is specified by the C++ standard. It is not necessary to debug the standard containers: it is only necessary to debug the code that uses them. That means a productivity gain (i.e. saved man hours, and hence saved development cost) as the programmer can focus on the job at hand, rather than rolling some new scheme (or duplicating some old scheme) for managing an array.

2) Most implementations of the standard library are written by people who know quite a bit about the compiler(s) and target system(s) that library works with. So they will probably be written better than any alternatives we might write for ourselves --- and hence more efficient in terms of speed and memory usage. Assuming, of course, that we require the same features (eg a resizable container, various guarantees of exception safety, no memory leaks, etc).

3) The standard containers do not (in themselves) introduce opportunities for memory leaks: when a container is destroyed, so is its contents. An C-style approach like that suggested by Jessehk is an opportunity for a programmer to forget to release dynamically allocated memory, and cause a memory leak. No similar opportunity exists with standard containers (unless, of course, the objects they contain introduce leaks).

4) Technically, it is true that standard containers introduce some overhead compared with raw arrays. But, if a deliberate attempt is made to ensure the same results with arrays (eg ensure no leaks when an array is resized or no longer needed) then the overheads of arrays are the same. There is no free lunch with software: if you have to implement a feature, then you will end up with overhead to get that feature.

5) It is true that it is possible to find cases when it is necessary to squeeze some performance characteristic out of your code and that is not possible with standard containers. Those cases are extremely rare in practice and, more importantly, usually only identified by use of profiling techniques i.e. measuring how a program executes, and identifying performance bottlenecks. Programmers, if they code for "efficiency", very rarely hit the real hotspots and therefore spend a lot of time lovingly hand-optimising code that doesn't need optimising. In other words, using a standard container in C++ (eg vector) may not always be the best approach, but it is the best approach to start with if you care about having a program work correctly without too much unnecessary effort.