Re: Article on possible improvements to C++
"Joshua Maurice" <joshuamaurice@gmail.com>
The style is like:
- 'delete' is forbidden in "client" code. It is privilige
of the the few library classes that serve as managers.
Like auto_ptr.
and who holds the auto-ptr?
It's a stupid rule anyway. It doesn't work in practice. The
real rule for memory management is not to use dynamic allocation
at all, except when the object lifetime is explicit (e.g. a call
in a telephone system). And of course then, your design (or
more directly, your requirements specification) determines when
the object should be deleted.
A new way I've been thinking about RAII is the following: All "free
resource calls", like delete, release mutex, close connection, etc.,
should be made only inside destructors. Specifically, all resources at
all times should have a clearly identified owner who frees the
resource in its destructor, or the resource is a stack object. It's
easy to extend this idea to shared ownership. Optionally, you can free
resources early as long as the resource still has an owner which would
still free the resource if you "accidentally" commented out the early
release.
The idea is that maintaining the invariant of "ownership" using
destructors produces easier to follow code, and less leaky code. RAII
is all about ownership responsibilities. I haven't taken enough time
to look through all examples, so please treat this as a tentative idea
from myself. Obviously there will be exceptions to this rule, I think.
That's practicly the same thing I was talking about. Not stupid at all, and
passed the test of the real life in practice. Possibly my ise of "client"
code is not clear -- I keep keep the handlers themselves (that have the
dtors) as "library" code. Which has a different life cycle. Maybe
"framework" would be a better name.
Early drop can be done through the .reset() interface (or its equivalent in
the manager), and commenting it out just results in keeping the thing little
longer.
I don't get what would be the problem with non-stack-frame limited
resources -- the manager may be at some outer block, or a member of the
class, but eventually it will bite the dust too.