List:MySQL++« Previous MessageNext Message »
From:Kevin Regan Date:June 10 2009 11:26pm
Subject:RE: Why dynamic allocation for Option objects?
View as plain text  
Thanks for the response.  However, I must disagree. There is definitely a benefit to
avoiding explicit memory allocation.  Here are some thoughts on the issue from
Stroustrup:

http://www.research.att.com/~bs/bs_faq2.html#memory-leaks

Around 95% of the memory leaks that I have found in our product over the last 5 years have
come from the explicit use of "new".  If memory allocation can be hidden in the STL, it is
best to do so.

Let's take as an example, the function in question:

std::string
DBDriver::set_option(Option* o)
{
        std::ostringstream os;
        std::auto_ptr<Option> cleanup(o);

Now, let's imagine that the constructor for std::ostringstream can throw an exception
(maybe it allocates a working buffer).  In that event, the memory for the option will not
be reclaimed when a std::bad_alloc exception is thrown.

This is just a simple example, but its simplicity is key in understanding why it might be
a good idea to avoid dynamic memory allocation when possible.

--Kevin


-----Original Message-----
From: Warren Young [mailto:mysqlpp@stripped] 
Sent: Friday, June 05, 2009 4:32 PM
To: MySQL++ Mailing List
Subject: Re: Why dynamic allocation for Option objects?

Kevin Regan wrote:
> I'm wondering why you do this:
> 
> connection->set_option(new mysqlpp::FoundRowsOption(true));

It's needed by set_option_default(), which lets you set an option only 
if it hasn't already been given an option.  It looks through the list of 
already-applied options and sets the given option only if one like it 
hasn't already been seen.

It could also be useful if the semantics of the underlying API ever 
change such that some options can only be set after the connection is 
up.  We could thus add a deferred option list, applying them 
automatically in DBDriver::connect() on successful connection.  Then 
MySQL++ client code that assumes you can set options at any time 
wouldn't have to change.

Sure, we could do both things without requiring dynamic allocation in 
client code by making copies of the objects when adding them to our 
internal lists, but why?  Much more efficient to just keep lists of 
pointers.

-- 
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    http://lists.mysql.com/plusplus?unsub=1

Thread
Why dynamic allocation for Option objects?Kevin Regan6 Jun
  • Re: Why dynamic allocation for Option objects?Warren Young6 Jun
    • RE: Why dynamic allocation for Option objects?Kevin Regan11 Jun
      • Re: Why dynamic allocation for Option objects?Jonathan Wakely11 Jun
        • RE: Why dynamic allocation for Option objects?Kevin Regan13 Jun
          • RE: Why dynamic allocation for Option objects?Kevin Regan13 Jun
          • Re: Why dynamic allocation for Option objects?Jonathan Wakely13 Jun
            • RE: Why dynamic allocation for Option objects?Kevin Regan14 Jun
              • Re: Why dynamic allocation for Option objects?Jonathan Wakely14 Jun
                • RE: Why dynamic allocation for Option objects?Kevin Regan14 Jun
                  • Re: Why dynamic allocation for Option objects?Jonathan Wakely15 Jun
                    • RE: Why dynamic allocation for Option objects?Kevin Regan15 Jun
                      • Re: Why dynamic allocation for Option objects?Jonathan Wakely15 Jun
              • Re: Why dynamic allocation for Option objects?Warren Young16 Jun
        • Re: Why dynamic allocation for Option objects?Warren Young16 Jun