Re: Article on possible improvements to C++
A few posts back you wrote
"OTOH, the real way to make correct [non-leaking] code is definitely
not going by [new/delete logging] info but through using consistent
RAII-like handling, and reviews enforcing it."
and
"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."
I disputed that RAII cured all emory leak problems (I was wrong to
suggest garbage collection as that is equally helpless in the face of
foolish application coders). You now appear to be agreeing with me,
but without explicitly saying so.
On 1 Dec, 11:27, "Balog Pal" <p...@lib.hu> wrote:
"Nick Keighley" <nick_keighley_nos...@hotmail.com>
<snip>
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!
Not sure how you arrived at the everything is FIFO assumption.
what else does RAII enforce apart from a FIFO allocation/deallocation
policy? If RAII is the solution to all memory management problems then
all memory management must be a FIFO based policy.
I was stating to use managers
you never mentioned them before. What is a "manager"? Like the
CallManager class in my example? Or like the CallList class in my
example?
-- and that managers can be non-locals. After
all we don't have so much places, so if you have a manager it can be:
- local in a block in the immediate function
- local in a block in a function somewhere up the call chain
- a global(/singleton)
ok.
you put responsibility of deallocation to the manager, and it will
eventually happen for all of them. There is a chance for pseudo-leaks,
what you call a pseudo-leak *I* call a leak.
we
probably not yet discussed. Like when you have a list with long life, =
keep
adding nodes and never remove any. Stuff can get stuck in managers that a=
re
global or live wery much up (say right in main()). Getting the resourc=
es
released only at prog exit may be not good enough, and act like a regular
leak in all practical terms.
right so you agree that RAII doesn't solve all resource management
problems? Goody.
No silver bullets. Think that is hardly news
to anyone reading this group.
so why did you say "with trivial style it is easy to make leaks
impossible"?
And pseudo-leaks are damn hard to discuss in abstract, in a forum: how yo=
u
tell whether some such node is yet needed in a system or not? Except by t=
he
particular design? ;-)
The point is that the managers in the latter category are not flooding th=
e
app -- you have only a few of them hopefully, and can pay close attention=
on
the content. And normally they are helped out with more local RAII
sub-managers.
ok. Not what you originally said though. I'll stop saying this.
<snip>
The most power of C++ comes from the fact it gives superior tools to crea=
te
a quasi-language in which you can most directly and expressively state th=
e
real aim of the program. To em the client or application code is what =
is
written in that latter language. That definitely don't have place for
keyword delete.
ah, now this is clearer. Ban new/delete from application code. Or
certainly delete.
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).
Like in these very cases. Client code shall no way attempt to implemen=
t
containers, string, etc -- but use them for good. :) It asks dy=
namic
stuff in indirect way, like resize, or invoking factory calls.
Eliminating dynamic memory use is rare -- probably extinct outside embedd=
ed.
yes but you don't have to have it application code
<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?"
In a single-doc editor the text buffer can be permanent.
(I guess text editor is not a good forum example,
I thought it was a good example...
:-)
the questions you rised
can be easily answered with a multitude of alternative designs, all with
pros&cons, yet trivially ensuring resource control -- but it would take a
book-worth amount of words. If really needed, pick some sub-part, or narr=
ow
it down.)
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
Undo also can be made with several approaches, like keeping snapshots of =
the
current state, or record request to play forward or back.
What you mean by "RAII alone"? Possibly we speak on distict tracks bec=
ause
you fill that term by different content...
well to me RAII enforces a stack discipline of resource allocation
(you yourself early said something about the resouce being released
when the stack frame is left).
The meaning tied to original mosaic is actually rearly meant literally --=
the most common use is RRID (res. release is destruction) leaving
allocation freeform -- still routinely referred as RAII. :-o
As I use it RAII stays for an even relaxed form, that allows the full
interface auto_ptr has, including reset() and release() -- just makes sur=
e
dedicated ownership is maintained, and destruction of a manager does mean
release of anything owned.
Maybe we could call it Controlled Resource Management, or Controller-base=
d
RM, or something like, but it would end up unused like RRID, and I did no=
t
see in practice RAII's tendency to force restrictions.
ok. But these more sophisticated resource management strategies can no
longer be termed "trivial"
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.
IMO discounting UB and other blacklisted cases they are.
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.
If you mean the "is-initialization" part, sure, it covers only a subset o=
f
cases.
oh by RAII I include RRID, I regard it as a single term for the entire
concept I don't see any in chopping it up.
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);}
<<
This does not make much sense to me, id call_list is the manager/owner of
calls, you don't use auto_ptr like that, and especially don't place the
result of lookup in auto_ptr.
I probably should have used a normal pointer.
There must be exactly one owner. Maybe you
meant shared_ptr, but it looks like overkill too.
And this is a good example what client code shall NOT do by any means -- =
leave call management with the call manager. So the whole thing becomes a
one-liner:
CallList::get_call(event).process_event(event);
and if it's a new call?
get_call within the manager can see whether it is existing or a new call,
create as necessary and return one by ref.
ok... That looks like a mere re-arrangement to me.
(This example implies no NULL
possibility, if there is one, make it
I was assuming lookup_call threw if it failed
if(Call * pCall = CallList::get_call(event))
pCall->process_event(event);
I'll not dispute my example should have more thought put into it