I'm in need of a simple wrapper for a fixed-size `std::vector` that can ensure atomic insertion.

Since my only real problem is with atomic insertion and I know beforehand the amount of entries it will have, I don't need any other parallelism related feature.

I am happy to have the initial allocation (`std::vector::resize`) run from the main thread, so it shouldn't need anything fancy.

Although there are great, free to use parallel vectors available, I think that my particular use case, being fixed size shouldn't require any fancy library (e.g. TBB).

I was thinking about something along these lines:

```
template <typename T>
class AtomicFixedSizeVector {
public:

    // a bunch of passthrough methods here...

    inline void reserve(size_t count) {
        m_data.resize(count);
        //m_data.reserve(count);
    }

    inline void push_back(const T& entry) {
        size_t index = m_count.fetch_add(1, std::memory_order_relaxed);
        m_data[index] = entry;
    }

    // I don't think I need this at all, but just in case
    inline size_t size()const {
        return m_count.load(std::memory_order_relaxed);
    }

private:
    std::vector<T> m_data;
    std::atomic<size_t> m_count;
};

```

It needs to be a wrapper to `std::vector` since the other parts of code take one.

I thought I'd ask this question as my knowledge of atomics is rather limited, and although it seems ok when executed, it's hard to tell if it's actually going well or I'm being lucky multiple times in a row.

Another question that I have is if I can trust `std::vector::reserve` to do the allocation on the spot or if it's implementation-dependent. I'm asking because if it allocates on the spot I don't need to override the behavior of `std::vector::size` and can use a passthrough wrapper there, too.

Please note that this is not a premature optimization but rather a post-mortem one, my insertion could be parallelized but only if it ends up adding onto a single block of entries.

This `std::vector` block of entries will only store `uint32_t` in case it helps.

---

Edit: 

The current use case is to insert from multiple threads, but this was designed knowing beforehand that by the time the data is accessed, the threads will have been joined.

There is an upper limit on the amount of values to be inserted so the vector will be preallocated before insertion.