Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Doing software 2d pixel buffers, blitting, etc. Someone was telling me there's absolutely no overhead involved in using an std::vector to represent objects, I was wondering if std::vector is indeed a good container for pixel buffers or if I should instead stick with a raw array like I've always used.


share|improve this question
I'd say, try it. or look at this question's answers… – melak47 May 1 '12 at 16:51
What I would say: profile it :) But in any case, if your raw array is dynamically allocated, there won't be any noticeable overhead (if any) when using an std::vector instead. However, keep in mind that the debug version of an std::vector probably has some additional checks which might make it look slower. – xcrypt May 1 '12 at 17:32
up vote 7 down vote accepted

When used properly, there shouldn't be any overhead in performance. But, they aren't exactly zero-overhead compared to raw arrays.

Size overhead

A typical std::vector container will use 3 pointers. Since you probably already track width and height yourself, your raw array could be done in one pointer since you already know the size.

Allocation overhead

You will incur some overhead when allocating the memory for the std::vector. However, this is the same overhead you incur if you allocate your own memory.

Zero-initialization overhead

std::vector will actually zero-init your memory when using resize(), which may or may not be significant to what you're doing.

But, from a performance standpoint, accessing a std::vector is the same as accessing an array.

share|improve this answer
zero-initializing using resize() is important, never knew that, thanks – OrgnlDave May 2 '12 at 3:11
Except in debug mode, where most testing will be done. The difference between std:: vector and a plain array can be massive, depending on compiler/library vendor and options. We actually ban all use of STl containers an write our own, just to ensure minimal overhead in debuggable builds. – Sean Middleditch May 3 '12 at 0:50

When you use an std::vector, it is basically a thin wrapper around an array, which itself is basically just a block of values much like any other buffer. But the real question is why you want to do this? An std::vector is an improvement over a normal array mostly in that you can resize it by adding and removing values - but this is not an operation you would normally perform on a pixel buffer. So the vector seems to give you no benefit here.

These days you rarely use an array of pixels anyway, since most graphics are handled more efficiently using a library-specific type that is suited to the underlying hardware.

share|improve this answer
One good reason to use a vector is that it will automatically free its memory on destruction. – Nathan Reed May 1 '12 at 19:56
So do arrays... – Kylotan May 2 '12 at 11:47
Not in C++, not if they're dynamically allocated, they don't. – Nathan Reed May 2 '12 at 16:40
That's only a concern if you don't know the size in advance, which you usually do if you're performing low level pixel operations. – Kylotan May 3 '12 at 13:07
You'd have to know the size at compile time to use static allocation. So you're proposing that the pixel sizes of all art assets and render targets be hard-coded into your game? Frankly, that sounds dumb. – Nathan Reed May 3 '12 at 16:26

It's fine to use an std::vector for pixel data as long as you're careful not to allocate/deallocate/copy memory unnecessarily. For example, when you create a pixel buffer, use the vector's resize method to set it to the number of pixels required, then don't change its size afterward. When passing buffers around from one function to another, use a pointer or reference to the vector rather than passing by value. If you need to assign one vector to another, use the swap method where possible to avoid unnecessary copies.

In release builds there should be no overhead in accessing individual pixels using the vector's operator[]; as xcrypt mentioned in his comment, there could be some overhead in debug builds since the vector might insert range checks.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.