I don't really know how to put it into words, but this is what I would like to do. It may seem counter-intuitive to 'limit' a template in this any case, but it's more of an academic query than anything else.
@helios:
It doesn't matter what the bool value means. It could be connection in use, or connection up. It's just a value associated with the map entry. Although, if it is state information, it probably should be an attribute of the connection and not the map entry.
Thank you for the responses. As AbstractionAnon had inferred, the boolean value was a flag to indicate whether the connection was in use by a thread or not. I had originally thought of keeping the in-use information being controlled by the pool object itself - and not the individual connections pooled within it. I am just curious, before I mark this query as resolved, why might one think that the in-use information be an attribute of the connection, and not of the pool managing that connection? Should the connection be aware that it is in use, or should that be left to the management class? (I suppose, what I am asking is what the majority of programmers think is the 'best' way to handle it; I code what makes sense to me, but I am always open to new ideas.)
AbstractionAnon: It does matter, because using a map for something like this is unnecessarily wasteful, and actually quite slow if he intends to use it for what I think he intends to use it.
What I suggest is keeping two lists. One of used connections and one of unused connections. That way you don't do any searching. There are also ways to make accessing an element of the list take constant time without returning neither a pointer (can't use std::list::erase() without a linear search) nor an iterator (exposes internals).
EDIT: Needless to say, I think the bool should be part of the object, not of the manager.
@helios
Would two lists be faster for keeping track of (no more than 255) connections, as opposed to a map? It might just be lack of experience on my part, but it would seem (to me at least) that removing an object from one list and adding it to another would be more costly than flipping a bit.
*Edit - As to what I'm thinking of using this for is part of the framework for a multi-player online game. I would want it to scale well, but would not expect to have more than a 255 concurrent game worlds operating at once. I would expect the database usage to flare on the start-up, which one would think, would require more database reads than during normal operation, so the pool would be auto-sizing, in the way that it would create, and destroy connections on demand (or lack-thereof); but it should never be under the stress of a web-server. This is just another learning experience for me; I don't expect the framework to be used for any commercial purposes.
but it would seem (to me at least) that removing an object from one list and adding it to another would be more costly than flipping a bit.
That's true, but in order to flip that bit, you have to find it first. Since your map is sorted by the pointer, you'll have to do a linear search. In the worst case, this would take O(n log n). Using a list, finding a free connection would take constant time, as the first element in the list of free connections will always contain a free connection (assuming it's not empty).
On average, using a map would take 270 times longer to find a free connection than using a list ((128*log(128))/1).
@helios - maps are usually implemented as a tree making the access time O(log n), but your point about the cost to search is still very valid. log(128) = 4.85