I am terribly, terribly sorry, just didn't quite think it through.
Given the semantics of std::auto_ptr, though, you could probably declare local auto_ptrs in the function, check for errors at the end of the function, and if there are no errors, pass ownership of the objects to permanent storage, something like this:

i.e. if everything loads successfully, we remove control from the auto_ptrs, and assign them to the global (or whatever) pointers, and then they don't delete the resources at the end of the scope.

Quote:Original post by Zahlman
What good are these "move semantics" of auto_ptr anyway? Why didn't anyone think to include the equivalent but with "copy semantics" in the standard library as well (and perhaps an array version as well)? Perhaps policy-based design (like std::auto_ptr<typename T, typename AssignmentPolicy>) would be useful here?

They are good for doing the things such as those that are listed in the link I posted above.

Considering why auto-pointer has move-sematics: When you copy an auto-pointer to another auto-pointer, the contained pointer is moved and the source becomes NULL. Now consider if you were to copy the pointer. The old auto_ptr no longer has ownership (it has moved), so basically it acts like a regular pointer.

And this is the reason that auto_ptr moves, rather than copies. If auto_ptr were to act like a regular pointer, it would not only require an extra flag (and check) in auto_ptr to implement, it is rediculiously more confusing than the copy-is-move sematics of the auto_ptr because now we can have variables of type auto_ptr that may or may not own the object in question. Leaving the programmer to puzzle which one must not be let out of scope.

Of course, if auto_ptr copied both pointer and ownership, then it would be a shared pointer, not an auto pointer.

CoreMeltdown,

I think the best solution is your third one. The allocated objects cannot exist independently, so their allocation and deallocation should be done in the same place at the same time.

One other thing -- since the pointers are accessible externally, you should set them to 0 after deleting.

I would hesitate to call setjmp a safe idiom to use because it magically jumps across functions/stack frames, messes up signals and in general suffers from the same problems as exceptions.

The standard C way to do it is with a bailout ladder:

err = do1()if(err < 0)	goto exiterr = do2()if(err < 0)	goto exit_undo1return 0;// successexit_undo1:undo1();exit:return err;

Deyja's code basically does the same thing but goes through gyrations to avoid goto (apparently only for the sake of doing so).