vector and dumping

Question

From what i know a vector is guaranteed to be continuous and i can write a chunk of memory to it and do send of fwrite with it. All i need to do is make sure i call .resize() to force it to be the min length i need then i can use it as a normal char array? would this code be correct

v.resize(numOfElements);
v.clear(); //so i wont get numOfElements + len when i push back
vector<char>v2;
v2.resize(numOfElements*SizeOfType);
while(...)
{
...
v.push_bacK(x); 
}
compress(&v2[0], len, &v[0], len);
fwrite(&v2[0], ....)

noting that i never push back or pop v2 i only resize it once and used it as a char array. Would this be safe? and if i also dumped v that would also be safe(i do push back and clear, i may dump it for testing)

Answer 1

v.resize(numOfElements);
v.clear(); //so i wont get numOfElements + len when i push back

Well, that above code snippet is in effect allocating and creating elements, just to destroy them again. It's in effect the same as:

v.reserve(numOfElements);

Just that this code is way faster. So, v.size() == 0 in both cases and v.capacity() might be the same as numOfElements in both cases too (although this is not guaranteed). In the second case, however, the capacity is at least numOfElements, which means the internal buffer will not be reallocated until you have push_back'ed that many elements to your vector. Note that in both cases it is invalid if you try accessing any elements - because there are zero elements actually contained.

Apart from that, i haven't figured a problem in your code. It's safe and i would encourage it so use it instead of a raw new or malloc because of the added safeties it provides. I'm however not sure what you mean by "dump v".

Answer 2

Indeed, std::vector is guaranteed to be contiguous, in order to be layout-compatible with a C array. However, you must be aware that many operations of the vector invalidate all pointers pointing to its elements, so you'd better stick to one type of use: avoid mixing pointer arithmetic and method calls on the vector.

Apart from that is perfectly correct, except the first line : what you want is

v.reserve(numOfElements);

which will allocate enough place to store numOfElements into the vector, whereas

v.resize(numOfElements);

will do the following:

// pseudo-code
if (v.size() < numOfElements)
    insert (numOfElements - size) elements default 
    constructed at the end of the vector

if (v.size() > numOfElements)
    erase the last elements so that size = numOfElements

To sum up, after a reserve you are sure that vector capacity is superior or equal to numOfElements, and after a resize you are sure that vector size is equal to numOfElements.

Answer 3

Yes you use a vector of char as a buffer for reading raw input.

// dynamically allocates a buffer of 10,000 char as buffer
std::vector<char>   data(10000);

fread(&data[0], sizeof(char),data.size(),fp);

I would not use it for reading any non POD data type directly into an vector though.

You could potentially use a vector as a source for a write.
But I would be very carefull how you read that back in (it may be easier to serialize it).

fwrite(&data[0], sizeof(char),data.size(),fp);

Answer 4

You're replacing reserve() with resize, you may as well replace

vector<char> v2

with

vector<Type> v2

This should simplify the code a tiny bit.

To be frank, it's the oddest use of vectors I've ever seen, but it probably will work. Are you sure you don't want to go with new char[size] and some sort of auto pointer from boost?

Answer 5

For something like this I would personally use a class like STLSoft's auto_buffer<>:

• http://www.synesis.com.au/software/stlsoft/doc-1.9/classstlsoft_1_1auto__buffer.html

As a disclaimer - I don't use the actual STLSoft library version, I've adapted my own template that is quite similar - I started from the Matthew Wilson's (the STLSoft author's) book "Imperfect C++".

I find it useful when I really just want a plain-old C array, but the size must be dynamic at runtime. auto_buffer<> is safer than a plain old array, but once you've constructed it you have no worries about how many elements are there or not - it's always whatever you constructed it with, just like an array (so it's a bit less complex than vector<> - which is appropriate at times).

The major downside to auto_buffer<> is that it's not standard and it's not in Boost, so you either have to incorporate some of STLSoft into your project or roll your own version.