When c++ returns, is it the same as a copy?

If I return a gigantic vector of integers from a function, am I better off just passing a reference to the function instead and having it filled that way? I'm wondering if returning a vector that takes up a very large amount of memory is a problem.

for example:

Code:

---


vector<int> getPrimes()
{
vector<int> primes;
//FILL vector<int> with a bajillion integers
return primes;
}

void getPrimes(vector<int>& primes)
{
//FILL vector<int> with a bajillion integers
}

---

Is there any difference whatsoever? (besides programming style)

There is a difference, but it also depends on your compiler.
Generally speaking, a copy will be made when you return the vector (that means all its contents will be copied).
However, it is also true that the compiler is allowed to make an optimization to avoid that copying, which essentially means that the compiler converts the code into the second variant.

So either you should not rely on it, or you should test if your specific compiler supports this optimization, by say, timing the time it takes to run the code in a loop of of n iterations.

Quick tip: unless you know how many primes you're going to generate, (as opposed to say, a function that generates all primes below N), consider using a deque instead of a vector. A vector starts out with a certain amount of memory available and if you try to put more elements than it can fit into this memory it finds a new, bigger block of memory and copies the whole thing into the new memory, which is exactly what you've expressed desire to avoid. Of course if you know how much memory you're going to need at the beginning, or a have a decent upper bound on how much memory you'll need, you can get around this using vector::reserve(). A deque is more clever with its memory management and can offer virtually all the features of vector without much extra overhead.

As Mozza314 said, you should consider deque. Actually std::string is the only container (well, theoretically it is not a container) that I return. I just don't meet many situation where I need to return a vector, so if I do, I pass it as a reference, because:

1. I will never forget about using this vector. If I attempt not to use the returned vector, I will rethink my design.
2. Mentioned (lack of) compiler optimizations.
3. It's pretty comfortable to operate on the destination vector, no need to create local one.

EDIT:
I forgot, I used to return vector in several functions of my project, but always as a shared pointer.

The annoying part of deque is that it is a little bit slower (I mean random access, since you need to acquire chunk first) and you have no idea how big chunks are.

You really should stick with a vector unless you believe you need another type of container. If it turns out a vector is slow, then you should consider alternatives.
That is, don't jump to conclusions that a deque will always be better.

Then again, it's always good to know your containers.

Quote:

---

Therefore they provide a similar functionality as the one provided by vectors, but with efficient insertion and deletion of elements also at the beginning of the sequence and not only at its end. On the drawback side, unlike vectors, deques are not guaranteed to have all its elements in contiguous storage locations, eliminating thus the possibility of safe access through pointer arithmetics.

Both vectors and deques provide thus a very similar interface and can be used for similar purposes, but internally both work in quite different ways: While vectors are very similar to a plain array that grows by reallocating all of its elements in a unique block when its capacity is exhausted, the elements of a deques can be divided in several chunks of storage, with the class keeping all this information and providing a uniform access to the elements. Therefore, deques are a little more complex internally, but this generally allows them to grow more efficiently than the vectors with their capacity managed automatically, specially in large sequences, because massive reallocations are avoided.

---

It is. But it's also a question of: are you always going to sacrifice random or linear iteration speed for the sake of a little gain in copying?
Therefore, it is usually best, unless you know you have specific needs, to simply use the default vector, and switch if it presents a problem.
Or you can try both, and time them, to see which one performs better in your program.
Remember that premature optimization is the root of much evil.

Quote:

---

But it's also a question of: are you always going to sacrifice random or linear iteration speed for the sake of a little gain in copying?

---

Your question is addressed by the quoted, and elaborated on, in the documentation I linked. FYI, deque does provide random access to elements and gets the same time complexity as vector on many operations including insertion and deletion. The difference between the two is very clearly stated in this thread and in other places. People's posts have made the information necessary. Make me a martyr for being helpful.

As for "a little gain in copying" well copying around is the only way reallocation works for contiguous memory. Unless you need contiguous memory (because you're doing pointer arithmetic?) it's an important optimization. Do I care what the OP does? Not really.

Quote:

---

Originally Posted by whiteflags

Your question is addressed by the quoted, and elaborated on, in the documentation I linked. FYI, deque does provide random access to elements and gets the same time complexity as vector on many operations including insertion and deletion. The difference between the two is very clearly stated in this thread and in other places. People's posts have made the information necessary. Make me a martyr for being helpful.

---

My point being that even though they are O(1), the constant time differs. Vector may be O(a) and deque O(b) where a, b are constants and a != b.
It is clearly stated in the documentation that random access is a little slower with deque.
That why I am simply stating "don't blindly jump into a container because you think it might be better." First, make a good argument that it is better. Secondly, prove that it is better.

Quote:

---

It is clearly stated in the documentation that random access is a little slower with deque.

---

I am sure that this will matter while you wait for vector to reallocate itself in the midst of calculating a "bajillion" primes to list.

Yes, it probably will, if it turns out you use it that way. But if you're not, and using a lot of random access, you will probably have to wait for the deque to churn all the time.
Just be aware of what you're doing. Don't blindly jump to a container.

I'd be really interested to see someone replicate similar results, but I think a really good article on this is:

An In-Depth Study of the STL Deque Container - CodeProject

It actually seems the biggest drawback of a deque is the time to reclaim the memory; the difference between element access is very small (~1.7%).

My biggest gripe from a quick overview with the article is that it doesn't mention what implementation it was tested on.
OK, having read the entire article, three things gripe me:
- There was no mention on what implementation the tests were made.
- There was no mention if it was done multiple implementations, and if so, which ones it were. That probably concludes it was done on only one.
- No source code was analyzed.
In other words, the article cannot be trusted. The statistics are useless. We cannot draw any conclusions from it.

Quote:

---

- There was no mention if it was done multiple implementations, and if so, which ones it were. That probably concludes it was done on only one.

---

The standard libraries have the same theoretical performance requirements, which can be exceeded (maybe) but AFAIK they aren't. Even if say the GNU implementation did some things faster by X amount, why would you draw a different conclusion about vector versus deque on the whole? Who wants to design software on the basis of "Oh I can use my favorite container with this implementation of the STL"?

Quote:

---

- No source code was analyzed.

---

To what end would you want to do this and why?

Quote:

---

Originally Posted by whiteflags

The standard libraries have the same theoretical performance requirements, which can be exceeded (maybe) but AFAIK they aren't.

---

It still doesn't rule out the question that some standard libraries may be poorly optimized. One of the comments mention that sorting a vector vs a deque ended in vector's facor with a 2.8x or so factor. This is a most curious result.
This covers the part that they must have the same theoretical performance requirements. I simply don't trust an implementation to conform to that when it comes to tests.

Quote:

---

Even if say the GNU implementation did some things faster by X amount, why would you draw a different conclusion about vector versus deque on the whole?

---

No.

Quote:

---

Who wants to design software on the basis of "Oh I can use my favorite container with this implementation of the STL"?

---

Certainly not I. That is why I would have liked to see this done on multiple implementations at the very least.
We also have to factor in the possibility of different compilers and how good they are at optimizing things.

Quote:

---

To what end would you want to do this and why?

---

To make sure the implementation is good and not some poor rip-off implementation.
The possibility that there are very poor implementations out there is not so farfetched.
And also give proof or backing to claimed test results.

Quote:

---

This covers the part that they must have the same theoretical performance requirements. I simply don't trust an implementation to conform to that when it comes to tests.

---

Well look at it this way: if they don't conform to theorectical performance requirements, your STL implementation is not standards compliant.

Quote:

---

To make sure the implementation is good and not some poor rip-off implementation.

---

If you are capable of making such an evaluation, precisely nothing prevents you from retesting, to get your personal results.

If someone's good implementation comes up with wildly different results, you have a point, but I just don't see why that would be. Particularly with the items being tested... why would memory management, which is only different in architecture, be a significant factor in results among STL implementations?

Quote:

---

Originally Posted by whiteflags

Well look at it this way: if they don't conform to theorectical performance requirements, your STL implementation is not standards compliant.

---

Indeed. But we have a lot of those, don't we?
Non-standard compliant compilers. Incomplete library implementations.
And some libraries may still be a factor or two faster than others since constants are ignored in big-oh, which I believe the standard states their requirements in.

Quote:

---

If you are capable of making such an evaluation, precisely nothing prevents you from retesting, to get your personal results.

---

I am way too lazy to make such a thing.
I am merely criticizing the results. If I really wanted to have good results, then I suppose I would have to test it, since I can't just demand someone else do it.

Quote:

---

If someone's good implementation comes up with wildly different results, you have a point, but I just don't see why that would be. Particularly with the items being tested... why would memory management, which is only different in architecture, be a significant factor in results among STL implementations?

---

And why would they not be? There is a lot of complexity there.
Allocating, moving, keeping track of elements, cleaning up, etc.
And then there's the big mess of allocation and deallocation which means allocators and new/delete which needs to be properly implemented.
I'm a pessimist. I can see a lot of things go wrong.