Christopher Smith wrote:
Once again: invoking GC() here and there provides no guarantee that an
object will get finalized
...
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, 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?
Yes. And you can do essentially the same thing in C# - put all the
resource allocation in objects whose constructors won't throw an
exception.
In C++ it's fine if they throw exceptions. *That* is the difference.
C# really should have put the creation inside the "try" block, yah.
Well, uh, *you* might think so. I write servers that are expected to
run indefinitely in the face of failures of all kinds of underlying
failures of service providers.
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.
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.
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.
>> I'm not 100% sure how you go about freeing a MAC address. ;-)
Pretty easy really. Usually a few calls to the device driver a few ARP
packets. Really helpful for HA systems.
Fair enough.
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
