MySQL++

If you call Connection::set_option(Option*), then Connection::connect(), then copy the Connection,
the copy constructor for the new Connection object will try to connect.
However, the connection attempt will likely fail.

Connection's copy constructor calls DBDriver's copy constructor, which calls DBDriver::copy().

DBDriver::copy() calls DBDriver::connect(MYSQL&), which calls DBDriver::connect_prepare().

DBDriver::connect_prepare() tries to apply any pending options. 
However, if the original Connection has already connected, 
it discarded the pending options in its DBDriver, 
so the new Connection's DBDriver will not have any options applied. 
This makes it very likely that the new object's connect() will fail.

See the experimental reapply-conn-opts-on-clone branch for a possible fix.

I will merge this into trunk — which will become the next release — if it fixes your issue.

There is one thing that may be surprising about the change: it doesn't clone the previously applied option set if it's cloning a disconnected Connection, because that tracks the way reconnecting a disconnected connection behaves.

I can be talked into changing this if you need it to work differently because in the simple reconnection case, libmysqlclient is remembering the previously applied connection options, so MySQL++ doesn't have to reapply them. But with the clone, libmysqlclient doesn't understand what's going on, so it could be argued that MySQL++ should reapply the previously-applied connection objects in this particular case.

No response from OP, so the branch will remain experimental and not merged into trunk. Perhaps for 3.3 if no one steps up and wants it first.