smellenbergh <sme### [at] skynetbe> wrote:
: But I would not guarantee that *all* memory leaks are fixed. 

  This is a big problem in C (and bad-written C++ as well). As the program
gets bigger and bigger it becomes harder and harder to keep track of
memory allocations (and other resources as well) that need to be freed.
  This is because there's no easy way to automatize the construction and
destruction of objects in C (we can speak of objects since povray is largely
object-oriented although it's written in C).
  Using proper OO in C++ should fix most of these problems. Each class handles
its own memory allocation and ensures (in its destructor) that everything
that is handled by the class is also freed.
  Of course using C++ is not fool-proof. It's perfectly possible to make
the same mistakes as in C inside the class. However, minimizing the size
of the class, making it and testing it carefully should minimize the risk
(testing a small class should be easier than testing a big bunch of
C-functions).
  Of course it's also possible to just use news and deletes in other places
than inside classes, thus creating the exact same problem. In my opinion,
however, if this is done, it's a design mistake. I myself seldom use
news and deletes outside well-defined classes (and of course never transfer
the responsibility of freeing the resource to other classes).
  Making small classes which handle carefully their own memory allocation
and freeing is a very powerful tool to get rid of memory leaks.

  By the way, memory is not the only resource that can be allocated and
freed. There are others as well, for example file handlers (ie. opened and
closed files), network connections, printers and so on. There can be also
program-specific resources that have to be allocated and freed.
  For this reason the Java-ideology is not good.
  In Java objects are allocated but the user doesn't have to free them. This
is good for memory handling, but it's bad for other resources.
  If the objects has to perform some operations before being destroyed
(such as closing files, internet connections or whatever), the user has
to call its "destructor" by hand. It's not called automatically. This will
inevitable cause resource leaks in bigger programs.
  Yes, I know that there's some kind of destructor function that can be defined
to a class in Java. This destructor is called before the memory taken by
the object is freed.
  However, this has a big problem: It's perfectly possible that the destructor
is never called. If the object is never freed (because the program just
finishes), then the destructor is never called.
  This is a big problem because some resources may not be freed at all.
However, even if the destructor is called, the problem is that you don't
know when it's called. If the object, for example, opens a window on screen
and closes it in its destructor, you'll probably get quite a lot of garbage
windows on the screen before they are eventually closed (if ever).

  Darn, I didn't mean to write a long story like this.
  Just forget it :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message