From: Warren Young
Date: June 5 2009 11:32pm
Subject: Re: Why dynamic allocation for Option objects?
List-Archive: http://lists.mysql.com/plusplus/8597
Message-Id: <4A29AAF6.5030500@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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.