Jonathan Wakely wrote:
> Eurgh. Why does that work, but not the OP's usage?
Because most of the time when you copy a Connection, you are merely
moving it to a new place in memory, not literally wanting to create a
duplicate connection to the server.
Imagine the chaos if you stored Connections in a set<>. Not that I
expect this happens -- ever? -- but its behavior is well-understood so
it makes a good thought experiment. I can't think of a real example
that requires less explanation.
Every time you inserted a new Connection, other nodes would be shuffled
around in the data structure (a red-black tree, typically) to keep it
balanced, copying the objects, bouncing connections to the DB server.
The insert() time would be absolutely no less than the cost of a single
connection attempt, and that minimum only when no rebalancing is needed.
Is that what you really want?
I could be talked into something like Connection::clone(), but changing
the copy ctor semantics seems like a bad idea.
> If copying is not safe, it shouldn't be allowed.
That ignores the useful use-cases where what we want is to just move a
Connection in memory. We understand that momentarily there exist two
Connection objects referring to the same underlying C API connection,
but one is doomed and won't be used again.
Query works this way, too.
