#include <iostream>
#include <vector>
#include <boost/shared_ptr.hpp>
class ResultSetItem {
public:
boost::shared_array<char> item;
int lengh;
}
typedef std::vector<boost::shared_ptr<ResultSetItem>> ResultSet;
vector of arrays
Author
I was looking for a way to use generate a list of unknown length arrays of characters using boost. A Vector of Boost::array<> looked promising, but it looked like you could only set the size of the array at compile time, not runtime. So the next idea was to make a vector of boost::shared_array<>, but I couldn’t figure out how to get a length out of shared_array. So the final idea I had was to make a thin wrapper class that would hold both the shared_array object and an int to indicate its size.
Is this the correct way to do this or is there another more boost/stl way of doing it?
Author
Some items in the ResultSet will be converted int a string later on so I figured using an array is a more efficient way of going about this. At least thats what I was thinking. That and the arrays are always going to be a static size once created, I just don't know what size they will be until they are created.
Quote:Original post by MrRage
Some items in the ResultSet will be converted int a string later on so I figured using an array is a more efficient way of going about this.
How so?
Quote:That and the arrays are always going to be a static size once created, I just don't know what size they will be until they are created.
So? What are you trying to gain here by using arrays instead of vectors?
Author
now that I think about it perhaps it would be better to use an vector for this. I don't know the size of the sub items until I iterate though the buffer and find the terminating char. If I'm using a vector I can be populating the sub-item vector while I do my checks - instead of double backing and copying the data into a static size object.
Author
Quote:Original post by Sneftelhere by using arrays instead of vectors?
Was trying to reduce overhead, I recall reading that vectors had some additional overhead over a boost::shared_array. But I'm sure this overhead is trivial after thinking about it.
Not sure if what you posted was just test code, but watch out, std::vector<boost::shared_ptr<ResultSetItem>> usually causes a parser error in compilers. std::vector< boost::shared_ptr<ResultSetItem> >. It's due to the >> or so I heard.
Quote:Original post by Sirisian>> actually works in VS2005, which some might say is rather scary. Still better to put the space there.
Not sure if what you posted was just test code, but watch out, std::vector<boost::shared_ptr<ResultSetItem>> usually causes a parser error in compilers. std::vector< boost::shared_ptr<ResultSetItem> >. It's due to the >> or so I heard.
btw, MrRage, the kind of extra overhead a vector would have over an array is 2 extra pointers, one of which enables you to query the length of it, and the other it's capacity.
In your case you just added an int to store the length, so you already have 2/3rds of the overhead anyway. If shared_array has some overhead as well), then you're saving nothing by just not using a vector.
Avoiding overhead is fine when you don't need it, but in your case you do need it, otherwise you have to implement the same thing yourself, which sure as hell wont be less buggy!
so you want a vector of array-like objects. You may want to use those objects as strings. You might try using std::string as your array-like object. It supports most, if not all, of the operations that vector does, including a push_back method.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
