****************************************************************
Point Four:

There is to be NO GARBAGE COLLECTION. A good programmer
cleans his own room after he is done.

R: OK, so tell me what the most common bugs are that come up in C
and C++ programs are down to. I'm pretty sure that memory
management related issues top the list. Even good programmers
make mistakes; it's part of being human. Finding a memory
related bug amongst a lot of code is hard, especially in a
project where people aren't always greatly familiar with the
codebase.

Point taken. Memory management is a serious source of bugs. That is true. However, there are times when I have problems giving up control. Perhaps the compiler should allow garbage collection to be turned on or off depending on the programmer's desire (possibly using a directive?). This would allow smaller projects to avoid the overhead, yet permit larger projects to benefit from the safety of GC.


*******************************************************************
Point Five:

R:I think that with the computing power available to us today, we
can afford GC. With the algorithms we have available to us now
(incremental GC, generational GC) it needn't be that costly. In
fact, for apps with short run time it can be more efficient
because we may not even have to bother freeing memory. It also
makes things easier in multi-threaded apps, where multiple
threads want an object that they will use at some point in their
execution that can be freed when they are all done. Tracking
when it's safe to free it can be fun. With GC, we don't have to
worry - the GC will look at the stack of each thread as well as
statics and free it when it's no longer reachable.

Point taken.

Admittedly, there is fun with ensuring timely destruction, if
that's something you want to make available in your language.
Destructors (or finalizers, call them what you like) creating
another reference to the object can be a real pain too. But
those can be worked around.

Good point. (Side note: I prefer the term "destructors." It sounds more powerful and sinister.

********************************************************************
Point Six:
6) Pointer math is something to think about. I would like to
see this as well. But presently I am focused on other
issues (component problems). Thanks for the reminder!

R: I was arguing against free pointer math. I think if you:-
(a) Force all memory access to be done in an array style
notation
(b) Do bounds checking

You'll be enabling people to write much safer code than it's
possible to write in C/C++ today.

I disagree. array notation can limit the control and power of the programmer within his code. How can I create objects that alter then call what first appears to be data, but is really code, without a pointer and the abilities of pointers "C" gives us.

Safer code comes from good style and patient, methodical planning.

Memory allocations should be checked and a component should never be allowed outside its declared turf. Bounds checking here will protect the system (that is another level of the project). Internally (OOP) should check bounds within the object. No object should be allowed to effectively rape another object by intruding on its boundaries.


****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.