2009/10/15 Warren Young:
> 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
> 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
> 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.
Assuming you are talking about a std::set<> then inserting elements
absolutely does not copy or asign any elements except the one being
inserted. Rebalancing only requires pointers to be adjusted. No
destructors will run as a result of inserting into a std::set.
Now if you're talking about inserting into a std::vector, then yes,
elements are copied and assigned.
> 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.
I realise it would be a large change, so I'm not going to argue for it.
What you really want is C++0x move semantics, so that a Connection is
movable but not copyable.
>> 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.
In the intended use case. My point is the other uses, like the OP's,
are not prevented by he API. An interface should be easy to use
correctly and hard to use incorrectly.
> Query works this way, too.
Two wrongs don't make a right ;-)