From: Warren Young
Date: April 20 2007 4:03pm
Subject: Re: Differences between query constructors
List-Archive: http://lists.mysql.com/plusplus/6547
Message-Id: <4628E458.5030700@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Joel Fielder wrote:
>> No.  Query::success_ indicates more than the result of the last query.
> 
> I see the behaviour, and it makes sense.  Maybe a slight tweak to the
> documentation would be in order for the sake of pedantry to make it
> clear that it's the object integrity rather than whether the last query
> worked.

If you explain what it really does you then get into having to wave away 
the fact that it's called "success", and then why we can't change it 
until v3.0.  Tiring... :(

I think what we really want to do here is rename Query::success() and 
Query::success_ to better match what they actually do.  Until we can do 
that, let's just quietly ignore this zit upon the face of the code.

> Also, if it's indicating object integrity in the copy constructor,
> success_ should presumably be based on whether there were no issues with
> init as in the normal constructor?

If you make a copy of a Query object in a bad state, you should get a 
Query object in a bad state.  If copying did something different, that 
would be a bug.

> Or maybe delete the copy constructor and I'll quit whining :)

Not 'til 3.0.  :)

But seriously, I really don't think we want to do that.  Query isn't 
simple enough that I trust a C++ bitwise copy to do the right thing. 
You need a real copy ctor to avoid disaster.

I'd argue that Queries shouldn't be copied at all, but the response to 
that is to make the copy ctor private, not get rid of it entirely.