 |
MySQLTalk.org
MYSQL discussions groups
|
| View previous topic :: View next topic |
| Author |
Message |
Joel Fielder
Guest
|
 Posted: Fri Apr 20, 2007 5:49 pm Post subject: Differences between query constructors |
 |
|
Hi,
Just wondered why there is a difference between the query constructors:
Query::Query(Connection* c, bool te) :
#if defined(_MSC_VER) && !defined(_STLP_VERSION) &&
!defined(_STLP_VERSION_STR)
Query::Query(const Query& q) :
#if defined(_MSC_VER)
Also, in the first constructor, if success_ is meant to indicate whether
the last query was successful, shouldn't it be left initialised at false
rather than set to true after calling init, assuming that no query took
place?
Joel |
|
| Back to top |
|
 |
Warren Young
Guest
|
| Posted: Fri Apr 20, 2007 7:45 pm Post subject: Re: Differences between query constructors |
|
|
Joel Fielder wrote:
| Quote: |
Just wondered why there is a difference between the query constructors:
|
No good reason. Probably just because few people actually use the Query
copy ctor, so it isn't causing real problems in the field. It's fixed now.
| Quote: | Also, in the first constructor, if success_ is meant to indicate whether
the last query was successful, shouldn't it be left initialised at false
rather than set to true after calling init, assuming that no query took
place?
|
No. Query::success_ indicates more than the result of the last query.
It's a flag to indicate whether _anything_ has gone wrong with the
object. Notice that you basically get this flag's value when casting
Query to bool. The semantics are:
Query q;
if (q) {
// life is good...
}
else {
// panic!!
} |
|
| Back to top |
|
|
Joel Fielder
Guest
|
| Posted: Fri Apr 20, 2007 8:02 pm Post subject: Re: Differences between query constructors |
|
|
| Quote: | 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.
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? Or maybe delete the copy constructor
and I'll quit whining :)
Joel. |
|
| Back to top |
|
|
Warren Young
Guest
|
| Posted: Fri Apr 20, 2007 9:03 pm Post subject: Re: Differences between query constructors |
|
|
Joel Fielder wrote:
| Quote: | 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.
| Quote: | 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.
| Quote: | 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. |
|
| Back to top |
|
|
Jonathan Wakely
Guest
|
| Posted: Fri Apr 20, 2007 9:15 pm Post subject: Re: Differences between query constructors |
|
|
On 20/04/07, Warren Young <mysqlpp@etr-usa.com> wrote:
| Quote: | 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.
|
(N.B. An implicitly-defined copy ctor isn't a bitwise copy except for POD types)
| Quote: | 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.
|
Actually, if you remove your user-defined copy ctor then the implicit
one will try to copy the std::ostream base and the std::stringbuf
member, both of which are non-copyable. So in this case simply
removing it would be even better than doing the private-and-undefined
trick, since you'd be guaranteed a compile-time failure if you try to
copy a Query.
With the private-and-undefined trick the Query class itself and its
friend SQLQueryParams could accidentally create copies, which wouldn't
be caught until link time.
Jon |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
