From: Warren Young
Date: October 15 2009 1:41pm
Subject: Re: mysqlpp::Connection copy c'tor segfaults
List-Archive: http://lists.mysql.com/plusplus/8731
Message-Id: <4AD7267F.4080602@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.