Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C++ (http://www.velocityreviews.com/forums/f39-c.html)
-   -   Exception guarantee question (http://www.velocityreviews.com/forums/t805392-exception-guarantee-question.html)

Noah Roberts 10-31-2011 07:39 PM

Exception guarantee question
 
If you have a member function like:

void add_job(std::auto_ptr<job> new_job)
{
jobs.push_back(new_job.get());
job.release();
}

can this be said to provide the strong guarantee? We know that both
get and release have no-throw, so the only point of failure is
push_back, which will fail if there's a memory allocation issue (since
ptr = ptr can't throw either). Under such a condition nothing is
changed about the jobs container, but the new_job is destroyed.

Because something changed, new job was destroyed, when an exception
was thrown I'm tempted to say it doesn't provide the strong
guarantee. On the other hand, the interface of the function
stipulates that ownership is being transfered and so cleaning up is
the right thing to do and perhaps fits the strong guarantee.

What do you think?

Alf P. Steinbach 10-31-2011 08:26 PM

Re: Exception guarantee question
 
On 31.10.2011 20:39, Noah Roberts wrote:
> If you have a member function like:
>
> void add_job(std::auto_ptr<job> new_job)
> {
> jobs.push_back(new_job.get());
> job.release();
> }
>
> can this be said to provide the strong guarantee? We know that both
> get and release have no-throw, so the only point of failure is
> push_back, which will fail if there's a memory allocation issue (since
> ptr = ptr can't throw either). Under such a condition nothing is
> changed about the jobs container, but the new_job is destroyed.
>
> Because something changed, new job was destroyed, when an exception
> was thrown I'm tempted to say it doesn't provide the strong
> guarantee. On the other hand, the interface of the function
> stipulates that ownership is being transfered and so cleaning up is
> the right thing to do and perhaps fits the strong guarantee.
>
> What do you think?


I think if you're using Dave Abraham's terminology, then it's sort of
weak guarantee: does mess up a bit (destroying that object), something's
changed after the call, but it preserves invariants.

The main issue is that the call messes with state at the call site.

In contrast, ...

void add_job( job* new_job)
{
std::auto_ptr<job> auto_destroy(new_job);
jobs.push_back(new_job.get());
auto_destroy.release();
}

does not have such an issue.

But I think better than trying to assign a generic category name,

just document the actual guarantee. :-)


Cheers & hth.,

- Alf

Werner 11-01-2011 08:15 AM

Re: Exception guarantee question
 
On Oct 31, 9:39*pm, Noah Roberts <roberts.n...@gmail.com> wrote:
> If you have a member function like:
>
> void add_job(std::auto_ptr<job> new_job)
> {
> * jobs.push_back(new_job.get());
> * job.release();
>
> }


From Herb Sutter's Item 22 in "More Exceptional C++":

"If an exception is thrown, program state remains unchanged"...
"implies commit/rollback semantics".

I would say from the callers perspective this is not the case,
as the auto_ptr will certainly be modified, but if add_job were
a member function of a class, the state of that class would
remain unchanged (and to me that is the effect that you are
looking for). Therefore the definition of strong guarantee
depends on what one considers "the program". The strong
guarantee would certainly hold for the the state inside
the function, but not for the auto_ptr.

OTOH the reason you are using an auto_ptr in the first place
is to communicate the fact that ownership "shall" be
transferred (you are forcing it). To me intent is conveyed
by using the auto_ptr in this case, and I would prefer your
solution to Alf's.

When I see and auto_ptr parameter, I know better than to touch
the auto_ptr after the call. When I see a "bald" pointer
parameter, I might as well delete the pointer after the call...

add_job( job );
delete job; //Was it cloned??? Ownership???

Regards,

Werner


All times are GMT. The time now is 11:21 AM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.