Odtnhj

I have a vector of binary data used by some middleware

std::vector<uint> data

The data inside this vector maps to a class Foo basically like that:

|uint|uint|uint|uint|uint|uint|uint|uint|uint|
| F o o | F o o | F o o |

Using a custom placement allocator (as described here Can I use an std::vector as a facade for a pre-allocated (raw) array?) I can now map the memory of the first vector to a vector of type std::vector<Foo>

But if I operate on the second vector the size of the first one is not updated.

Another approach would be to encapsulate the first vector std::vector<uint8> in a custom container which behaves like a std::vector<Foo> but this is a lot of effort (and I cannot use Boost).

Any ideas for an elegant solution?

The situation is very different to the linked question. You aren't dealing with preallocated storage, you have data for objects already there. Furthermore, you wish to have both sides be able to modify the vector, or in other words they have shared ownership.

This isn't trivial. You can provide a "view class" that offers another set of operations on the same vector or have a family of free functions do the same. Either way they must have reference semantics.

A free function example

template<typename T>
void push_back_foo(std::vector<uint8_t>& vec, T&& t)

 auto it = vec.insert(vec.end(), sizeof(Foo), );
 new (&*it) Foostd::forward<T>(t);

And so on for all the other functions. They map operations on the Foo side to operations on the uint8_t side.

A side note: doing pointer arithmetic on the resulting vector is formally undefined behaviour because there is no array of Foo there. When dealing with overlaying binary data with a facade, it is generally understood that compilers won't burn down your house and such formalities are ignored.