Depends on the complexity of your game. For something basic it really won't be much of an issue to have an array/vector of 10 bullets and only draw/update active ones as you describe. If you do need more you can always resize that vector. It's probably better than creating and deleting bullets each time.

Just use a vector of structs and work on the vector. You can do this through a function, or else encapsulate the vector in a class that manages it and does the work on it. When you iterate the vector to update the bullets and you find an object that's flagged as dead then swap and pop and continue processing from that point. If a new bullet is fired, just emplace it to the vector. Vector retains its memory and you'll avoid the costs that you'd otherwise get from constant allocations and releases. The only thing you need to make sure of is that you never increase the vector during iteration. In fact, if you like, you can set up your system to log the maximum size that the vector reaches during play and when you're satisfied that you've found a good upper-bound you can use vector.reserve() to allocate all the memory up-front (increase it by 50% just for kicks).

You're going to have a hard time finding a better pattern than this, and we're talking about something that almost certainly is not a performance issue in the first place.

All the class really needs is two public functions like T* GetPooledObject() and ReturnPooledObject(T* pObject) (You don't have to make this a templated thing, but you might find you want to use several different pools, depending on your game)

Why should any individual bullet ever be singled out and removed from its context? Bullets don't really get up to much in terms of decision-making or individual behaviors. Anything that you're doing to one bullet probably needs to be done to all bullets, so the encapsulating class can manage it. There's no reason to "check out" and "check in" individual bullets. All that does is defeat contiguity and remove the ability of the class to maintain its invariants.

I have used object pools combined with linked lists for this kind of thing in the past. Provided you don't need random access to a projectile it should work just fine.

Pool allocates and stores references to the objects, it can create a bunch upfront based on and educated guess and expanded if needed at runtime, uses a vector behind the scenes and a pointer to the last unused item.

Then you just run though your linked list in the update function advancing and collision testing. It is then extremely fast to add/remove projectiles from the linked list and return/retrieve them from the pool. Most of the time there will be 0 allocations and 0 vector resizing/copying. It is not as cache friendly as blasting though a flat vector but plenty fast enough and the ease of implementation is a real plus.

There are no doubt other ways, this is just something I have used successfully many times and is both easy on the GPU and minimises memory allocation/GC.

b