List:MySQL++« Previous MessageNext Message »
From:Chris Frey Date:November 2 2005 3:21am
Subject:Re: mysql++ connection/resuse destructor bug
View as plain text  
On Tue, Nov 01, 2005 at 07:05:20PM -0600, David Wojtowicz wrote:
>  I guess my main point was that it is too easy to create code that looks
> perfectly valid (like my example), but had unintended side effects, due to
> the hidden nature of destructors being called as objects go out of scope.
> 
> Here is an even simpler piece of code that runs into the same problem.
> 
> int main(int argc,char **argv) {
> 
>   ResUse use;
>   Connection con(....);
>   Query q=con.query();
>   use=q.use("....");
>     
> }

I do agree, it is too easy to write code like this, and I'm in favour
of making it hard to use code wrong.  Good example too.


> I don't know if the C++ standard prescribes the order in which destructors
> must be called when multiple objects go out of scope or not, but gcc anyway
> reasonably destructs them in the reverse order they were constructed in.

Yes, the C++ destruction order guarantees a bug with the above example.


> In the above code 'con' gets destructed before 'use', which is a problem.
> Granted, if you understand the internals of mysql++, then you can see why
> this is a problem.  But it's not entirely obvious to anyone else.  After
> all, you can do without repercussions:
> 
> {string A;  string B;  B="text";  A=B;}

The mysql++ classes are not completely independent like string, so even
if we wanted to, I don't think that goal is appropriate.


>  2) Make the default ctors for ResUse and Result private (which is not
> unlike there being no default ctors for Query and Connection)  This would
> require making Query a friend of both classes.    It would prevent you from
> compiling the problem code example above... and force you to create a ResUse
> from an existing object, thus in the proper order.  Though it won't help in
> my original example where I explicitly called delete on the Connection.

I like this idea.  It helps to force the correct order of construction.
The only problem I can think of is that it may make it harder to build
a class that contains a ResUse object.  It forces the query to happen
in the constructor of such a class, or it forces dynamic allocation.

- Chris

Thread
mysql++ connection/resuse destructor bugDavid Wojtowicz1 Nov
  • Re: mysql++ connection/resuse destructor bugChris Frey1 Nov
    • RE: mysql++ connection/resuse destructor bugDavid Wojtowicz2 Nov
      • Re: mysql++ connection/resuse destructor bugChris Frey2 Nov
      • Re: mysql++ connection/resuse destructor bugChris Frey2 Nov
        • Re: mysql++ connection/resuse destructor bugWarren Young2 Nov
      • Re: mysql++ connection/resuse destructor bugWarren Young2 Nov