Game Server Structure

[Xornand]

It wasn't clear to me, thus my clarifying answer... but it's no problem, I didn't take it as offensive. Cheers

[StDH]

That's also the reason I said that a lot depends on what you'll be doing with the data because if you only add/remove from the middle occasionally, then you probably won't gain much from using std::list - but if it's something that is done every game frame and especially on a container that is supposed to be storing large objects, then that's a different story.

Players are allowed to jump thru portal every 5 seconds, so that's the reason of std::deque.
std::list is bit useless because it's doubly-linked to object in front & back, but yeah it's effecient for large objects

[Xornand]

Players are allowed to jump thru portal every 5 seconds, so that's the reason of std::deque.

IMHO that's a bad reason. std::deque is used for fast insertions and deletions at the front and the back... but you said, you'd be removing from the middle. If that's the case, then std::deque is a poor choice and instead, as mentioned above it'd be more efficient to either stick with a linked-list or (in your particular case, because you're really just storing pointers) a standard std::vector.

std::list is bit useless because it's doubly-linked to object in front & back, but yeah it's effecient for large objects

Could you elaborate?

[StDH]

std::list has big memory usage.
std::vector is reallocating in every insertion.

std::deque is perfect to store players.

[Strelok]

Reallocating the vector (you can always reserve) is usually faster than having to read all the pointers to the back of the list (a lot of cache misses)

[StDH]

std::vector::reserve = pain in multiplayer map without limit, this is just for npcs (static amount)
std::deque = can insert/delete in middle, that's what i need for players ofc.

[Nexus]

Huh? What do you mean?

I meant using char arrays to protect strings against resizing makes no sense whatsoever, it's not just a bad choice because it's C

Actually you'd be surprised. Whilst theoretically list does do the removal quicker, the search for what to remove is still O(N) for both vector and list, and vector has better cache coherence so performs this search significantly faster due to less cache misses. Fast enough that vector can outperform list overall, simply because all those cache misses add up.

I cannot emphasize this enough. A lot of people who decide between STL containers only look for asymptotic time complexities and forget about the whole other range of factors which are at least as important.

Just use std::vector and change the container if you encounter problems. When there are few elements (up to hundreds or even thousands), everything is blazingly fast so that you don't even care about linear search. StDH, apparently you missed my advice concerning efficient removal in std::vector. Removing elements in the middle alone is not a reason to choose std::list (let alone std::deque, where it's not even more efficient in theory).