Re: Do you use a garbage collector (java vs c++ difference in "new")
"Chris Thomasson" <cristom@comcast.net> wrote in message
news:GqCdnX114-xROp3VnZ2dnUVZ_gGdnZ2d@comcast.com...
"Mike Schilling" <mscottschilling@hotmail.com> wrote in message
news:f3YLj.2517$h75.303@newssvr27.news.prodigy.net...
"Mirek Fidler" <cxl@ntllib.org> wrote in message
news:aacaa5d9-a013-4fbc-9e3f-db7c118eeda0@c19g2000prf.googlegroups.com...
On Apr 11, 11:44 pm, Razii <DONTwhatever...@hotmail.com> wrote:
Which "older OS"? Some 30yo?
How about mobile and embedded devices that don't have
sophisticated
memory management? If a C++ application is leaking memory, the
memory
might never be returned even after the application is terminated.
This is more dangerous than memory leak in Java application,
where,
after the application is terminated, all memory is returned by
VM.
If VM is able to return memory to OS, so it should be C++ runtime.
The JVM can (in principle, at least) compact its heap and return
the now-free space to the OS. An environment that doesn't allow
memory compaction (which includes most C++ implementations) would
find this impossible.
Heap compaction is nothing all that special. Its certainly not tied
to a GC. Not at all.
Good thing I neither said nor implied that it is, then. However,
all Java VMs that I know of support it. for the obvious reason that
GCs which don't compact would fail pretty quickly with heap
fragmentation [1]. Most C++ implementations don't support it, because
their pointers are implemented as machine addresses.and they lack a
mechanism to fix up the pointers after a compaction.
1. Plus the fact that if you have enough information to do GC, you
have more than enough to make compaction work.