Re: Article on possible improvements to C++
On 30 Nov, 17:41, James Kanze <james.ka...@gmail.com> wrote:
On Nov 30, 10:11 am, NickKeighley<nick_keighley_nos...@hotmail.com>
On 27 Nov, 10:59, "Balog Pal" <p...@lib.hu> wrote:
"NickKeighley" <nick_keighley_nos...@hotmail.com>
As I'm not a C++ expert I was wondering if this post (and others in
this thread) was going to earn me a Larting. I do however have
opinions (opinions are like...) on softwasre developmne tand I have
developed and maintained C++ systems.
I just get bugged by the "RAII solves all memory management problems"
line and the implicit assumption that all objects follow a simple FIFO
allocation/deallocation protocol. Don't these people ever tackle real
world problems!
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.
ah, thanks. Entity objects... is that what you call 'em. And yes RAII
fits very nicely with tansactions. If the transaction can't complete
then all the things it allocated are safely freed.
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 it stuck in my head. Even if its an ideal not entirely
reachable ("never make mistakes"!) its worth keeping at the back of
your mind. Avoid "oh it doesn't matter I can always clean it up
later".
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).
yes
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.
oh, goody so I wasn't so far out in the out-field
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).
if things are of variable size? Oh yes use std::vector (or other
suitable container).
I'm beginning to form the rule of thumb that all uses of new[] are
errors. Or at least need looking at very hard.
And of course then, your design (or
more directly, your requirements specification) determines when
the object should be deleted.
yes. There is no doubt when a call finishes. Well /almost/ no doubt,
some group calls get a little hairy.
<snip>
[simple example] (too simple if you ask me)
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...
sorry, "who deletes the text buffer?"
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.
but it's no longer solved by RAII alone
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.
exactly, the client code has to cause the object to be created somehow
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.
sorry, the points at which delete are called is well defined with
RAII, it's just the point at which an "entity object" is released is
not specified by a FIFO protocol and hence RAII is not a complete
solution.
-- and that automation can reliably be used to do the
deletes you need. All of them.
<snip>
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.
thanks
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,
stupidly I went to The Hungarian Side of the programming nature. I
meant of course std::auto_ptr<Call>. The example was cobbled together
rather quickly and may be buggy. Second attempt:
CallManager::process_event (std::auto_ptr<Event> event)
{
std::auto_ptr<Call> call(0);
if (is_new_call (event))
{
call = CallFactory::create_call (event);
CallList::add_call (call);
}
else
{
call = CallList::lookup_call (event);
}
call->process_event(event);
}
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.
I was assuming that happened inside
call->process_event(event);