Re: Scope variable pattern
Re: Scope variable pattern
- Subject: Re: Scope variable pattern
- From: Roy Lovejoy <email@hidden>
- Date: Fri, 11 May 2007 09:12:12 -0700
On May 11, 2007, at 8:54 AM, Erik Buck wrote:
I am a very accomplished C++ programmer with more than a decade of
experience writing and maintaining C++ code. I have to ask, why do
you want to replace two lines of code that are explicit and
intention revealing with the trick of relying on a side effect of
constructor/destructor semantics that conceals the intent of the
code ?
struct ScopedDoing {
ScopedDoing () { /* doing.. */ }
~ScopedDoing () { /* clean up.. */ }
};
..
<some function body>
{ ScopedDoing aScopedDoing; ...
}
..
The poor slob who has to figure out what your code does now
absolutely must go look up the implementation of the ScopedDoing
class in order to understand what <some function body> does.
easy answers. pick any one.
a) it's exception safe. if someone throws in the middle of the scope,
or calls a routine that throws in the middle, the clean up will take
place. not so with a second line. huge benefit
b) it's 'return in the middle' safe. see 'a'. huge benefit .
c) 'poor slobs' have to look up *any* api call if they are unfamiliar
with it. proper naming conventions can facilitate the recognition
factor. unsubstantial drawback.
d) it's a known, reliable design pattern that has been used
successfully for 'more than a decade'.
this is in no way obfuscated. it is documented thoroughly,
it facilitates clean code, and if done well, often eliminates memory
leaks 100%.
IMHO one of the best c++ features that an accomplished c++ engineer
has in his arsenal.
my $0.02, since you asked..
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden