Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!hudson.lm.com!netline-fddi.jpl.nasa.gov!elroy.jpl.nasa.gov!swrinde!pipex!uunet!zib-berlin.de!informatik.tu-muenchen.de!lrz-muenchen.de!news.informatik.uni-muenchen.de!news.muc.de!isis.muc.de!mike
From: Mike.Chapman@muc.de (Mike Chapman)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
X-Newsreader: TIN [version 1.2 PL2]
Organization: Home
Message-ID: <1995Jan2.220809.508@isis.muc.de>
References: <D16Ho3.4BE@lcpd2.SanDiegoCA.NCR.COM> <3e2bj6$43a@network.ucsd.edu> <3e30ag$ar1@wariat.wariat.org> <19941231.180912.4252 <19950102.030603.354344.NETNEWS@UICVM.UIC.EDU>
Date: Mon, 2 Jan 1995 22:08:09 GMT
Lines: 121
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:105581 comp.lang.lisp:16235

David Hanley (dhanley@matisse.eecs.uic.edu) wrote:
: Mike Chapman (Mike.Chapman@muc.de) wrote:
: : David Hanley (dhanley@picasso) wrote:

: : [ stupidity deleted ].

: : :         Did it ever occur to you that GC was not instilled into the
: : : C++ language for a reason?  That there are many good reasons for
: : : preferring manual memory management?

: : The point is that many of us find the reasons Bjarne gave
: : for not incorporating GC into the language to be invalid.

:         And, ( this might shock you ) many of us think that
: his reasons _are_ valid.  Fancy that!

The sarcasm is unwarranted.

There are some valid reasons for not wanting to *use* GC in an
application but none of these are (IMVHO) valid reasons for not
including GC as part of the language definition.

: : The are very rare occasions and very *few* reasons for preferring
: : manual memory management. The only valid one I know of is
: : for guaranteeing hard real time performance (look up the
: : definition).

:         1) Better overall performance.
:         2) Less memory usage.
:         3) Better VM behavior( this point is debated ).
:         4) Ease of creating compilers across a number of platforms.
:         5) Retaining the ability to manipulate pointers.

Only the last one of these is valid.  But there are very few (if
any) valid reasons (IMHO) to ever want to manipulate a pointer (ie doing
arithmetic on it) in C++ apart from writing memory management
routines of one kind or another (I include persistence and
(de)serialisation as kinds of memory management).
By memory usage I am taking the liberty of meaning physical memory
requirement and not virtual memory requirement.

Most of the reasons given in (older) 'C' texts on why you would
want to do this (efficiency) are no longer valid with quality
compilers.

:         There are more.  Guess you didn't think about this very hard,
: eh?  And I know what hard real time performance is.  

Many people are under the misconception that 
    real time == interactive or fast.

: Why do you assume
: that someone who disagrees with you is ignorant?  

I don't and never said I did. The chances are pretty good that
you are pretty ignorant about many things in this world including
but not limited to 18th century Lithuanien Poetry.

: It might be that you
: are the ignorant one, and saying things like that will go a long way
: twoards proving it.

My point was (which, as far as I can perceive, you do not seem to
have grasped, which could be because I have not expressed myself
very clearly, or it could be that you are just too hard headed to
actually listen to someone else's point of view) is that GC does
not preclude manual memory management whereas ommitting GC from
the language standard makes it hard to tack a good GC on in a
portable way (particularly in the presence of clever optimising
compilers).

[The standard compiler on one of the platforms our code has to
run on does one of these optimisations which makes the use of
something like the Boehm GC dangerous unless you take special
precautions with automatic pointer variables which ensure that 
the compiler cannot perform these optimisations.]

Also the code for a GC must include some machine and possibly
some compiler dependent stuff. Some of this will usually have
to be written in assembler. This kind of programming should be
provided by the language system and not by me.

The best thing would be if GC was required in C++ implementations
and had a standardised interface for those people who want to
turn it off on certain sections of code etc. There should also be
a standardised compiler switch to remove it from the executable
completely for those applications which really do not benefit
from it.

This would keep everybody happy.

I have seen estimates which state that approximately 90% of C++
programs would benefit from automatic GC. This concurs with my
experience which includes control, real time OS, DSP as well as
'applications'.

Why should the majority be put at a disadvantage?

: : Using reference counting is just about the dumbest way of
: : performing any kind of automatic GC there is.
: : It has the worst performance of all, and simply does not
: : work for most interesting practical data structures.

:         This is a complete red herring.  Who ever mentioned refrence
: counting?  Furthermore, this statement is not true for all cases,
: or even the majority.

You mentioned reference counting in the title of your article.

It does have the worst performance of all dynamic memory
management schemes. See the excellent papers by Henry Baker who
has done a significant amount of research in this matter. Also it
does not work for most interesting practical data structures.

This is not a red herring. The fact is that a large amount of C++
code uses reference counting schemes to manage memory.

-- 
Mike Chapman <Mike.Chapman@muc.de>
   A fanatic is one who can't change his mind and won't change the
   subject. -- Winston Churchill --
