Re: Article on possible improvements to C++
On Dec 1, 9:45 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
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!
It's the latest silver bullet. It's quite possible that it
actually works for some real world problems. I've just never
seen any where it does: it doesn't work for anything which looks
like a server, for example, or handles external events (which
includes GUI's). (It does work when the "dynamic objects" are
variable length arrays, used in numeric
calculations---std::vector is a good example. Except, of
course, that an implementation of std::vector that only deletes
in the destructor doesn't work.)
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.
I forget where I got the word from; I know I looked for a word
for it for a long time. Anyway, it seems as good as anything
else, and I've not heard any other suggestions, so that's what I
call them.
And yes RAII fits very nicely with tansactions. If the
transaction can't complete then all the things it allocated
are safely freed.
Yes. And once you know the transaction has succeeded, you
release the permanent objects from the RAII holders.
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".
In a well run organization, it's not "I never make mistakes",
but rather, "Even the best programmers make mistakes, so we set
up various controls (code review, unit tests) to catch them
before they actually get into production code."
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
No. That doesn't mean never use std::auto_ptr---I use it a lot.
But most of the time, if the transaction succeeds, the pointer
will be recovered by calling the release function. At the
simplest, auto_ptr holds the pointer until the object is
successfully enrolled in all of the places necessary for it to
receive the appropriate incoming events.
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).
Exactly. Let the standard library worry about dynamic
allocation. (There are obviously exceptions to this. For
example, if you're implementing std::vector:-).)
I'm beginning to form the rule of thumb that all uses of new[]
are errors. Or at least need looking at very hard.
That's been my rule since at least 1992 (when I implemented my
first array classes). Within the implementation, you almost
always want to separate allocation from initialiation, so it's
::operator new() and a placement new per element. And outside
the implementation of such classes, you use such classes, rather
than new[].
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.
And what happens if someone goes off, and forgets to hang up?
There are also time-outs, and such. But it's application level
logic: not something you define as a coding rule, but rather
something the domain specialists define in the requirements
specifications.
<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?"
The user? When the text buffer disappears is generally part of
the requirements specifications, see e.g. the commands bdelete
and bwipeout in vim. My point was just that you don't generally
delete an std::string or whatever when you delete text in an
editor.
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
Certainly not. (My comments were meant to expand on yours, not
to disagree.)
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
Yes. I was responding to you AND the people you responded to,
at the same time.
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.
The quoting above is deep enough that I'm no longer sure who's
saying what, but some smart pointers are not that deterministic.
Saying that an object will be deleted when the last pointer to
it is destructed is saying that unless you know the exact
lifetimes of all of the pointers, you don't know when it will be
deleted. You're basically using smart pointers as a slow and
bugging implementation of garbage collection. Except that the
indeterminisms of garbage collection are well known.
[...]
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>.
But you don't want std::auto_ptr here.
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);
Which is a member function of of call.
I think we basically agree. (I learned the pattern when I
worked on telephone systems, but I've since learned that it
applies in just about all servers and all event driven systems.)
--
James Kanze