List:MySQL++« Previous MessageNext Message »
From:Kevin Regan Date:June 12 2009 10:55pm
Subject:RE: Why dynamic allocation for Option objects?
View as plain text  
I was taking another look at this issue (please see the code below to following along with
my issue).  If the DBDriver::set_option returns non-empty error string, wouldn't it have
deleted the objected contained in o that Connection::set_option will call typeid(*o) on?

My application is currently crashing in set_option call and I'm trying to track down what
might be going on.

--Kevin


bool
Connection::set_option(Option* o)
{
	error_message_ = driver_->set_option(o);
	if (error_message_.empty()) {
		return true;
	}
	else {
		if (throw_exceptions()) {
			throw BadOption(error_message_, typeid(*o));
		}
		return false;
	}
}

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

	switch (o->set(this)) {
		case Option::err_NONE:
			applied_options_.push_back(o);
			cleanup.release();
			break;

		case Option::err_api_limit:
			os << "Option not supported by database driver v" <<
					client_version();
			throw BadOption(os.str(), typeid(*o)); // mandatory throw!

		case Option::err_api_reject:
			os << "Database driver failed to set option";
			break;

		case Option::err_connected:
			os << "Option can only be set before connection is established";
			break;
	}

	return os.str();
}

-----Original Message-----
From: jonathan.wakely@stripped [mailto:jonathan.wakely@stripped] On Behalf Of Jonathan
Wakely
Sent: Thursday, June 11, 2009 1:43 AM
To: Kevin Regan
Cc: plusplus@stripped
Subject: Re: Why dynamic allocation for Option objects?

2009/6/11 Kevin Regan:
>
> 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.

The ostringtream default constructor shouldn't throw, but it wouldn't
hurt to swap those two lines so that the pointer is guarded
immediately.

I detest raw pointers to dynamically allocated memory, and would
advise using an auto_ptr in the interface, so it is explicit that
ownership is being transferred and that the address of a static or
local variable should not be passed in.

std::string
DBDriver::set_option(std::auto_ptr<Option> o);

The existing function could then be changed to simply forward to that
one, and ideally deprecated.

Jonathan
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