--- In email@example.com
, "Steve Hayes" <hayesstw@...> wrote:
> On 24 Jun 2013 at 12:00, Tom wrote:
> > A major characteristic of genealogical software is the need to have
> > persistence of objects in the programs. That is, you need to be able to create
> > a software object to represent some genealogical concept (e.g., person,
> > family) and you need that object to continue being alive within your program.
> > It has to have a lifetime beyond the individual software modules that create
> > them, or display them or compute with them. Objects like these are called heap
> > objects, meaning they exist in a largish, originally unstructured area of
> > computer memory. The heap is carved up into smaller units of memory, to hold
> > your objects, as the program proceeds. Because of this you need to use a
> > programming language that helps you manage the heap. The popular
> > "object-oriented" languages provide you with the support you need. These
> > languages are Java, Objective-C, C++ and C#. All four of them actually manage
> > to hide almost all issues of heap use and heap management from you. Note that
> > C is not on the list. C is not object-oriented, and C does has only a very
> > simple interface to the heap. C can be used in an object-oriented manner by
> > how you structure your code, and the heap interface of C (the malloc and free
> > system calls) can be encapsulated in a higher layer abstraction in C, but
> > using C in this manner is not for the beginner.
> The way I understood it is that C and C++ allow (require) the programmer to
> manage memory, whereas in most of the others this is handled automatically by
> the compiler.
> And isn't the kind of information you refer to as objects ultimately stird on
> disk in a database, called from there and stored there again once it has been
> interrogated or manipulated?
You are right about C and C++. Java has always been a language where the compiler
managed the heap for you (see note below). Objective-C has evolved. In Objective-C
you used to manage the heap using reference counting that you did by making
calls to retain, release and autorelease. The latest version of Objective-C has a feature
called ARC (automatic reference counting) which essentially makes Objective-C
equivalent to Java in terms of heap management. Basically the compiler inserts all
the right heap management calls at the right places. I have shifted over to using ARC
in all my development and it is wonderful.
The proviso (the note below) is that programmers can still be stupid and the
compilers can't help that. Heap management means creating new objects when
needed and returning objects when no longer needed. Smart compilers are smart by
figuring out when an object will never be referred to again and then getting rid of it
automatically. The compiler does this by inserting code that keeps track of how many
times a heap object is referred to. When this drops to zero the object is removed.
But, programmers can (and often do) write code in which objects are still referred to but
will never be used. A classic situation occurs when one object refers to another, and
that other object refers back to the first object, but no other references to either
object exists. Most compilers are not smart enough to recognize this case and the
two objects persist for the life of the program, essentially as leaked memory. There
are "garbage collection" algorithms that can find these leaks, but they are expensive
to run and usually cause your programs to suddenly pause. Good monitoring tools
used during development can find these problems for you.