Darren New wrote:
Christopher Smith wrote:
Tell me how you ensure the destructor runs on an object you
dynamically allocated and forgot to call destroy on?
Object pools, allocators, garbage collectors, etc.
?? C++ doesn't have garbage collectors,
There are entire company's whose existence would contradict that. No GC
in the standard, but you most definitely implement GC (indeed, most GC's
are implemented in C or C++, with assembly only being used for
optimization).
and GC doesn't guarantee an object will get finalized, and now you're
telling me you can ensure your destructor runs by using garbage
collectors?
It wouldn't be my first choice, but some C++ GC's have synchronous API's
that block until all objects in the GC'd heap have had their destructors
invoked.
So, when a process can no longer log successfully, you'd rather keep
it running than let it die, so it's parent can report the problem and
spawn a new child?!?!
No. When logging throws an exception, the exception gets caught and
logged.
/me just let's the logic of that sink right in. :-)
A *good* compiler should be able to do escape analysis and realize
that perhaps the object isn't even reachable (which is often the
case) outside of the block.
Agreed. That's another way of doing GC.
It's not quite the same thing, but it can be a helpful tool for
optimizing GC as well. My point is, all compilers fail to warn or
enforce good conventions. It is the nature of the beast.
But let's take your RPC example. Let's say that I'm using an RPC
service, and it is holding on to 400 petabytes of information for
me. Perhaps it'd be good to tell it to free that up before I ask it
to allocate a new 400 petabyte dataset for me, yes?
No, why? If it knows you've stopped using it when you stop having a
reference to it, why do you care when it gets freed?
Sigh. That's my point. The RPC service *doesn't* yet know that I've
stopped referencing it unless I explicitly tell it to.
You're talking about a different kind of system than I am. The service
*does* know.
This some kind of special, relativity violating RPC system? ;-)
--Chris
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
