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
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.