Re: Future Objective-C changes
Re: Future Objective-C changes
- Subject: Re: Future Objective-C changes
- From: "Clark S. Cox III" <email@hidden>
- Date: Wed, 21 May 2003 15:08:53 -0400
On Wednesday, May 21, 2003, at 14:55 US/Eastern, Quentin Mathi wrote:
Le mercredi, 21 mai 2003, ` 13:56 Europe/Paris, Clark S. Cox III a
icrit :
Note that you have to have three calls to [gc
restoreGraphicsContext]; (actually one plus one per exception handler
and one per return statement). This leads to very hard to maintain
code. If you use a stack-based utility class, you only have to
declare it once, and you've basically enclosed that function in a
protective bubble, you've just guaranteed that after you leave the
current stack frame for any reason, you've properly reset the global
state.
This type of stack-based utility class is quite logical and straight
forward. You want to mack some change, but only have it persist for
the current stack frame, what better way than to tie the actually
setting/resetting of that state to entering and leaving the stack
frame?
... is it possible to have an example of a stack-based utility class,
I don't understand what you mean here.
It's a common C++ idiom, basically it looks something like:
class SaveMyState
{
public:
SaveMyState()
{
//Save some state, or acquire some resource
}
~SaveMyState()
{
//Restore the state or release the resource
}
}
And it's used like so:
void foo()
{
SaveMyState stateSaver; //Constructor will be called, saving the
state or acquiring the resource
SomeFunctionThatMightThrowAnException();
//If an exception is thrown, all local variables are destroyed, so
that means that stateSaver's destructor
//will be called, restoring the state, or releasing the resource
if(blah)
{
return;
//When a return is encountered, all local variables are destroyed,
so that means that stateSaver's destructor
//will be called, restoring the state, or releasing the resource
}
//when the function exits normally, all local variables are
destroyed, so that means that stateSaver's destructor
//will be called, restoring the state, or releasing the resource
}
To achieve the same effect without such a class, you'd need code like
so:
void foo()
{
SaveTheState();
try
{
SomeFunctionThatMightThrowAnException();
if(blah)
{
RestoreTheState();
return;
}
RestoreTheState();
}
catch(...)
{
RestoreTheState();
throw;
}
}
So basically, such a class can be used to ensure that the state is
restored, regardless of how the function is exited. Of course, this is
a little more tricky in an Objective-C++ context, because (currently)
ObjectiveC exceptions does not unroll the stack in the same way that
C++ exceptions do, so this won't work when ObjectiveC exceptions are
involved. ObjectiveC doesn't really have an equivalent concept, but as
others have pointed out, there are ways of achieving a similar effect.
--
http://homepage.mac.com/clarkcox3/
email@hidden
Clark S. Cox, III
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.