Originally Posted by Daved
When you say that the C++ source uses its own buffer class that uses the same memory so there's no need to allocate and delete it over and over, what do you mean? Is this memory shared between multiple buffers? Is the buffer destroyed but the memory left around for the next time a buffer is created?
If you use a vector (or string or deque), what will most likely happen is that if you clear the container, the memory will not be deallocated. So if you are using the same vector over and over, just inserting a bunch of stuff, then using it, then clearing the vector, then you will probably not notice much of a problem.
If, however, the other buffer class keeps a pool of memory around independent of what instances of the class are in use, then there might be some differences. What I would do is go ahead and use the vector class. Then, after you have done a significant portion of the implementation, you should profile the code. A good profiler will tell you what code is causing the largest slowdowns. If it turns out that your code is spending a lot of time allocating and deallocating, then you can consider taking action. What usually ends up happening is that the vector (or other container) works fine and your slowdowns are in other areas of the program.
If profiling does show a slowdown due to allocation and deallocation, then you should customize your container with an allocator. Boost has a pool allocator that you can use with STL containers that basically keeps a pool of memory for the container to use which helps avoid excessive allocation and reallocation. I would only worry about this if the profiling showed it to be necessary, but if it is necessary it is not terribly hard to implement and you still get to use the STL containers you want.
And I agree with Ken Fitlike that vector<BYTE> sounds like the best option from what little we know of the situation.