On Mar 30, 4:04 am, "DE" <[EMAIL PROTECTED]> wrote:
>
> The curly brackets have no functional meaning...
"Curly brackets have no functional meaning"? Surely you must be
thinking of C, but not C++. Some of the most powerful idioms (idia?)
of C++ make use of functionality that runs when a closing bracket
causes local variables to fall out of scope. In fact, this technique
is crucial to writing exception-safe code.
The most obvious has to do with memory allocation/deallocation, and
the STL template <auto_ptr>. <auto_ptr> was invented to prevent this
problem:
{
// create a pointer - let's pretend I need a pointer
// and can't just allocate blah as a local SomeObject
SomeObject* blah = new SomeObject();
// do something with blah
blah->doSomething();
// do something else - OOPS! exception happened
blah->doSomethingBad();
delete blah; // never got here - memory leaked
}
Instead, define blah using <auto_ptr>:
{
// create a pointer - let's pretend I need a pointer
// and can't just allocate blah as a local SomeObject
auto_ptr<SomeObject> blah ( new SomeObject() );
// do something with blah
blah->doSomething();
// do something else - OOPS! exception happened
blah->doSomethingBad();
// but we don't care because when auto_ptr goes out
// of scope, it deletes its pointers allocated
// memory
}
I was on one C++ project in which our coding guidelines said something
to the effect of "no delete statements except in cleanup templates,"
meaning that all allocated variables had to be wrapped in some form of
auto_ptr template to ensure resource release on delete, even in the
face of exceptions.
So that closing '}' actually DOES do something functional, in running
the destructors of all locally declared variables.
But why should Python folks care, since garbage collection takes care
of our basic memory needs without all this auto_ptr<Stuff> stuff?
Well memory allocation is only one of these symmetric function cases.
Garbage collection doesn't do anything for us in:
- database transaction commit/rollback
- mutex lock/unlock
- web client session close/release
- release of any other kind of allocatable resource
AND, it does this deterministically, not "at some possible time in the
future" like GC.
(Yes, I know that CPython's ref counting scheme *does* release memory
immediately, but this is an implementation-specific behavior.)
Prior to Python 2.5's "with" construct, the closest Pythoners could
get was to use try/catch/finally, and put the resource release code
into the finally block. There are also some decorators on the Python
wiki that encapsulate this "be sure to close the door" logic into some
friendlier syntax (even if it does use that ugly '@').
-- Paul
--
http://mail.python.org/mailman/listinfo/python-list
