From: ian@syacus.acus.oz.au (Ian Joyner)
Subject: Re: C++ Critique (3 of 4) (long)
Organization: ACUS Australian Centre for Unisys Software, Sydney
Date: Wed, 15 Apr 1992 12:34:35 GMT

nagle@netcom.com (John Nagle) writes:

>       Many of his points are well-taken.

Thank you. I have had many personal mails to the same effect, and no hate
mails. I am rather thankful for this, and perhaps my point that language
criticism need not, and should not be a religious matter, or mud slinging
has been well taken. Having said that, I may well get flamed. Please don't
break the run though.

>       A key point, as is gradually becoming clear, is that a higher
>level of language safety than C++ provides is required to support 
>software components.  If a user is to use a software component without
>looking at its innards, software components must be more than minimally
>robust.

Yes I think that is the major point about reusability that I realised while
developing the critique. If components are to be reused (as opposed to merely
reusable) then the client must trust the component. Customers in reality
rarely trust suppliers. They always have checks to assure that what is
supplied is what they expected, even if such checks become subconcious. I
always check the change I am given at a shop, even though I am hardly aware
that I am doing this. The creed that C trusts programmers becomes more and
more thin everytime I hear it. I have been programming for a long time, and
I still don't think I can be trusted, I will probably keep making mistakes,
especially in an environment where we are developing products that we have
never done before. Addressing the problem-oriented issues becomes the 
interesting thing, not the machine-oriented things.

>       The notion that pointers are too low-level a construct may be
>a good one.  See Hermes for an example of a language without pointers
>or arrays.  This idea has not yet caught on but may be the next big
>step in programming.  It will take several more languages to get it right,
>though.

I think there have been many languages without pointers (but maybe not
arrays), or at least C style pointers. So I think that pointer-less
technology is already here with us.

>       Garbage collection is not a real solution for a language with
>destructors.  It's adequate for getting memory back, but if important
>actions like the release of locks and closing of windows, files, and 
>other objects take place at deallocation, deferred deallocation can
>produce very strange results.  Reference counts combined with
>uncontrolled pointers result in unreleasable circular lists, of course.
>This remains a major unsolved problem with pointer-based languages.

I don't think that garbage collection and destructors go together. An 
object is garbage collected when it has already left the universe.
Calling a destructor at this time gives the object an opportunity to
link itself back into the universe. Maybe this would be a new kind of
'bug' (a misleading term in itself) that could be termed a 'ghost' :-)
Maybe the solution is to limit a destructor in a GC scheme to very
limited operations. Of course, if you don't have explicit 'delete',
then where you want to close a file by deleting the file object,
you could instead explicitly call close on the file. Any further
operations on the file would indicate that not all references have
been lost, and should cause an error in the file object. I don't
think there is anything particularly magic about destructors that
cannot be achieved in other ways. But it is nice to think that
certain things will be cleaned up in an object when it goes out of
scope. But then the difficulty in programming with dynamic entities
is determining exactly when things have gone out of scope, and are
no longer referenced. As software becomes more complex, I can only
see this problem getting worse.

Not all garbage collectors work on reference counts, because of the
circular link problem. I am not a GC expert, but I do not accept that
all GC is bad, but there certainly have been some bad garbage collectors.
Certainly, as more and more concurrent processors come into being in
the not too distant future, it is not too hard to imaging how garbage
collectors will be continuously running with no effect on response time.
-- 
Ian Joyner                                     ACSNet: ian@syacus.acus.oz
ACUS (Australian Centre for Unisys Software)   Internet: ian@syacus.acus.oz.au
Tel 61-2-390 1328      Fax 61-2-390 1391       UUCP: ...uunet!munnari!syacus.oz