Re: Article on possible improvements to C++
On Nov 30, 10:11 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
On 27 Nov, 10:59, "Balog Pal" <p...@lib.hu> wrote:
"NickKeighley" <nick_keighley_nos...@hotmail.com>
<snip>
OTOH, the real way to make correct code is definitely not
going by that info but through using consistent RAII-like
handling, and reviews enforcing it.
I keep on seeing things like this. How exactly does RAII
deal with allocations that don't follow a simple [stack
based] model?
Insert some example of the model you think problematic.
anything that doesn't follow a stack model. A graphical
editor. A mobile phone system. You are at the mercy of the end
user as to when objects are created and destroyed. With the
phone system people can drive into tunnels or JCBs (back-hoes)
can dig up comms links (that really happened once).
Certainly. RAII doesn't apply to entity objects (which means
most dynamically allocated memory). On the other hand, it's
very useful, for enforcing transactional semantics within the
transaction which handles the events: it probably applies to 95%
or more semaphore locks, for example.
As test runs will hardly cover all possible paths
including errors and exceptions, so relying on the empty
leak list from a random run is nothing but illusion of
being okay. While with trivial style it is easy to make
leaks impossible.
so explain to me how I trivially remove all possible memory
leaks from my programs.
"Remove" is not the way. You start from nothing -- that is
assumed leak-free ;-) and add all the stuff in a way that
can't leak. So your program is always leak-free.
ah, my computer science lecturer used to tell us that a blank
piece of paper had no bugs. Programmers then just went on to
add bugs.
It's true, and the secret to quality programming is to not add
bugs. That's why people use code review and unit tests and any
number of other techniques (like not writing overly complicated
code to begin with).
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.
- The result of every new goes immediately to one such
manager. That's about it.
these things always seem to solve the easy cases (ok they used
to be the very hard cases!) but not the hard cases.
Certainly there are a few cases where ownership is
transferred --
a few!
so look what happens to result of release(), Detach() and
similar calls, that is IME natural.
Same thing applies to other resources: files, handles, GDI
resources, locks, transactions.
except for transactions, yes
As an example, you may look some old Petzold examples to
struggle with raw WIN API in pure C -- and see how the same
thing looks using MFC's CFont, CBrush and similar
wrappers.
I've wrappered Win32 in C++. Yes, RAII makes life easier.
The difference is incredible in readability and clearness.
As a side effect DBWIN no longer explodes on any random
program reporting a zillion of lost resources.
If you want a very simple example,
no, I don't want a simple example
think a program that processes text manipulating strings all
its time. A C++ solution would use std::string, (or any of
the much better string classes). Doing all the
passing-around, cutting, concatenating, etc.
consider a text editor that allows the user to delete text.
Who deletes the string that holds the deleted stuff and when.
That's probably not a good example. The text buffer holds the
text before it's deleted, and the deleted text itself is never a
separate object, unless...
What if the editor has Undo/Redo?
Then you save the deleted text in a redo record. Which will be
deleted when the requirements specifications says it should be
deleted.
Without having a single new or other allocation in the
*client* code of the program.
the client code is gonna have to do something to trigger the
new. Call a factory for instance.
Which comes down to the same. Sometimes the factory method is
justified---it may be preferable to check pre-conditions
beforehand, or to register the created object with a transaction
(so it can be correctly deleted in case of rollback).
While obvoiusly doing a zillion alllocations and
deallocations. Can you describe a way to introduce a leak?
forget to call the thing that triggers the delete.
Why invest in better patches instead of cure the problem
at roots?
because you can't remove the problem at its root. If you
want true dynamic allocation then you need to trigger
delete somehow. Unless you add garbage collection to C++.
Sure you can, and many of us do it in practice. C++ has
destructors that are called automaticly at well defined
points
the points are not always so well defined.
-- and that automation can reliably be used to do the
deletes you need. All of them.
As, unless you start doing WTF things deliberately just to
prove idiots'
I'm not *trying* to break things.
endless resources, destructors will be called matching
constructors, and when leaving a scope by *any* means.
but leaving scope is *not* the correct time to delete some
objects!
It it is the correct time, then you don't want dynamic
allocation to begin with.
CallManager::process_event (EventAP event)
{
CallAP call = 0;
if (is_new_call (event))
{
call = CallFactory::create_call (event);
CallList::add_call (call);
}
else
{
CallAp call = CallList::lookup_call (event);
}
call.process_event(event);
}
when this finishes the call should very definitly not be
destroyed! The CallManager (or some class this is delegated
to has to track what goes into CallList (the list of currently
active calls) and also be careful about rmoving things from
it- when they are destroyed.
I'm not sure what CallAP is, but this looks like a familiar
pattern (except that I'd probably keep the newly created call
object in an auto_ptr until I'd successfully returned from
CallList::add_call). And of course, if the event is "hang up",
and that brings the connection count in the call down to zero,
it is the call itself (in a function called from
Call::process_event) which will do the delete.
--
James Kanze