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
