Vector that can hold any POD - c++

Question

Is there a sort of vector that can hold any POD? something like:
anyvector v;
v.push_back<int>(1);
v.push_back<somestruct>({1, 2, 3});
and access it with:
int a = v.get<int>(0);
somestruct b = v.get<somestruct>(1);
I know there must be an overhead to save the offsets of each element, but it should be less than the overhead of vector<boost::any> which is my current solution.
The operations I need is insertion to end, removal from end and random access.
I know its not a problem to implement one, just asking if there is a ready one.
Edit: A solution that uses pointers to store data (boost::any, boost::variant) is a big overhead over using linear storage which is what I'm looking for.

Answer 1

I've never heard of one, and I'd be surprised if one exists, given how
very special it is. It shouldn't be too hard to implement, however,
using two vectors, a std::vector<unsigned char> for the raw memory
where you put the objects, and std::vector<size_t> to map the indexes.
As long as it only contains POD's, you can use memcpy to insert the
elements. Just don't forget to respect alignment. And that the index
array maps indexes: don't try to put pointers into it, since these will
be invalidated by later push_back.
For that matter, it shouldn't be too hard to implement one which holds
any type, even non-PODs, using placement new and explicit destruction.
The only real problem would be alignment. When you insert into the
vector, you'ld have to also save an instance of a polymorphic destructor
type. This could be a little tricky, but is doable, at least in
practice. Basically, you'ld be duplicating what boost::any does, but
instead of the pointer to dynamic memory, you'd get the "dynamic memory"
from the second array.

Answer 2

std::vector<boost::variant<int,somestruct,...>> v;
v.push_back(1);
v.push_back(({1, 2, 3});
a = boost::get<int>(v[0]);
provided you know which types have to be handled at declaration.
-- edit
As JohannesD said boost::variant impacts the size of each element, but
as James Kanze said, maintaining a vector of offset is very similar to boost::any and I am not sure you can really be more compact.
Depending on your exact requirement, another solution may work for you.
Store internally a different container for each type, this may not be a lot better than directly using multiple vectors, but you can store extra information like the last few elements stored. and you still got everything in one place.
Something like :
template <template <class,class> class C, typename T, typename ...Args>
struct map_ { //FIXME: return a list of type C<T1>,C<T2>...
};
template <template <class...> class C, typename ...Args>
struct fill_ { // Hack to parametrize map by Args on GCC 4.6
typedef T<Args> type;
};
template <typename... Ts>
struct hvec
{
std::map<std::string,fill_<boost::variant,map_<std::vector,Ts>> vec_map;
std::size_t last_id;
std::string last_typeid;
template <typename T>
T get(std::size_t i)
{
std::vector<T>& v = vec_map[typeid(T).name];
return vec[i];
}
template <typename T>
std::size_t push_back(const T& e)
{
std::vector<T>& v = vec_map[typeid(T).name];
v.push_back(e);
}
};
Of course you could replace vectors by maps and thus remember elements id, this would fulfill your requirement but add extra costs and still implies one "address"/key by element. However in this case you will never have to remember the type of an element at a given offset.

Answer 3

So you don't want pointers: that means you need an element type big enough to directly contain any POD. Given that POD objects can have arbitrary size, this is obviously impossible.
If you have a set of candidate types, it seems like you can have a bounded-size discriminated union, but isn't that what Boost.Variant does? The documentation indicates it will be stack-based (so presumably inline) where possible. How did you measure this "big overhead"?

Answer 4

you could try soemthing like the combination of vector and pair
enum ElementType : unsigned int
{
ET_INT,
ET_WHATEVER
};
vector < pair < void*, unsigned int >* > v;
pair < void*, unsigned int > prv;
int i;
prv.first = &i;
prv.second = ET_INT;
v.push_back( &prv );
it would be your choice to store objects by reference or by value. access to singloe elements would be like that:
int a = *( int* ) v.at( 0 )->first
that would give you fixed vector element size and info on the type of every stored element. when storing objects by reference watch out for lifetimes and namespaces, but i prefer conversion from types and making sure that the void pointers are valid instead of passing hugh sized parameters to functions everytime.
hope it helps;)

Answer 5

A std::tuple can store a sequence of arbitrarily sized elements, but only a fixed set of them.
An arbitrary number of elements with arbitrary types at runtime sounds error prone and very unsafe. What do you expect to happen if you do the following?
anyvector v;
v.push_back<Foo>(Foo());
int i = v.back<int>();
You'd be lucky if the implementation could provide you with a runtime exception, and I don't think there's any way that an implementation of anyvector could guarantee that. For example, if it tried to use RTTI it would run into the problem that there's actually no guarantee that two type_info objects that refer to different types won't be equal.

Answer 6

I think to get the best approximation to what you want, you will need to build your own data structure. You can base your type off of two implementation types:
std::vector<unsigned char> blobStorage_;
std::vector<size_t> offsetMap_;
This is effectively a serialisation blob implementation with the ability to offset access individual objects serialised into the blob.
When you want to push_back an object, you
serialise it into the end of the blobStorage
add the offset (front of your new object's blob) into the offsetMap
Similarly when you want access element that you think of as vector[n], you
get the offset from offsetMap_[n]
deserialise the object as the supplied type from blobStorage_[offset]
Both of these operations are order O(sizeof(object)), but effectively constant.
Usually, though, when you want to do something like this, you do "actual" serialisation into a blob, where by "actual" I mean you actually design the serialisation into your program. This typically means that you use a standard header to the storage of your types that gives a type ID and potentially size information. The reason you would normally do this is because you lose the type information when you serialise, and in the usage pattern you have indicated (where the type is supplied in the get), you are building a very fragile program with a lot of unwritten contracts. You don't typically want your programs easy to break in a professional environment working with others. So you can make it much more robust by storing type ids and registering the types with their type ids inside a greater serialisation design. Then, the "vector" will know how to deserialise and present the correct type of object.

Answer 7

std::vector stores elements as a contiguous array
In such an array each element has a starting address sizeof(Elem) past the previous element
POD types may be arbitrarily large
There is no way to have a vector of arbitrarily large objects, because sizeof(Elem) is unlimited.
The answer, unless you can restrict yourself further, is simply no.
If you can set an upper size limit, then yes it is possible, without any overhead. POD objects can be used without explicit construction, or killed without explicit destruction. So you can just create a vector of std::array< char, N > and reinterpret_cast the elements to your desired type.
typedef std::vector< std::array< char, pod_size_max > > pod_variant_vector;
template< typename destination >
destination &get( pod_variant_vector &vec, std::size_t index )
{ return reinterpret_cast< destination & >( vec[ index ] ); }
template< typename destination >
destination const &get( pod_variant_vector const &vec, std::size_t index )
{ return reinterpret_cast< destination const & >( vec[ index ] ); }
Be sure not to use the value of any such object before it has been initialized using the same type you are getting.