In article <35dukd$gkl@Venus.mcs.com> maney@MCS.COM (Martin Maney) writes:

>   > Dr. Stroustrup says in *The Design and Evolution of C++* that is it a
>   > matter of *when*, not *if* garbage collection will be added to C++.

>   Ahem.  You have lost one very important word that Stroustrup uses (at
>   least in the printing I have here).  That's OPTIONAL garbage collection,
>   which is rather an important difference, I think.

I think we were all talking about optional garbage collection.  The
"Safe C++" proposal allows you to write C++ code exactly as you do
now, with no garbage collection, and *optionally* you can write "safe"
modules that use garbage collection.

>   And I think he says it will be AVAILABLE, not ADDED TO.  The
>   latter seems to suggest that it will become part of the basic
>   language definition: I believe Stroustrup clearly says that he
>   does not think this will be the case (on about page 220, in the
>   discussion of the pros and cons).

Garbage collection for C++ is already available in several forms, and
has been for some time.  If it's ever to become a commonly used
feature (which Stroustrup definitely implies), there will have to be a
standard at some point down the road, which says that if your
implementation of C++ provides garbage collection, it will look like
this....  Stroustrup does seem to think that it could be a defacto
standard rather than an actual standard, but perhaps this is a bit too
optimistic.

|>oug /\lan
   <nessus@mit.edu>

Douglas Alan (nessus@mit.edu) wrote:
> In article <Cw3r2E.9r7@undergrad.math.uwaterloo.ca>
> r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

> >   Maybe there was a reason these "problems" weren't addressed.  If you
> >   haven't already, read "The Design and Evolution of C++", by Bjarne
> >   Stroustrup.

> Dr. Stroustrup says in *The Design and Evolution of C++* that is it a
> matter of *when*, not *if* garbage collection will be added to C++.

Ahem.  You have lost one very important word that Stroustrup uses (at
least in the printing I have here).  That's OPTIONAL garbage collection,
which is rather an important difference, I think.

And I think he says it will be AVAILABLE, not ADDED TO.  The latter seems
to suggest that it will become part of the basic language definition: I
believe Stroustrup clearly says that he does not think this will be the
case (on about page 220, in the discussion of the pros and cons).

I have most decidely *not* found my nirvana -- I am merely
pointing out problems in the language that could be solved, with
relatively little pain.  Other languages have other flaws, but
there's nothing wrong with stealing the parts that worked well.
I see the "safe C++" proposal as being no more radical than the
introduction of function prototypes in Ansi-C.  (Did that
committee have a different "scope and mandate"?)  The arrays
introduced by the Ellis-Detlefs proposal look like they come
from some template class, and (it occurred to me late last
night) "*Array" and "Array++" could be defined to yield either
the first element of Array or the obvious sub-array (and a
syntactic anachronism would be preserved, much like "car" and
"cdr" in Lisp).  This would not change the appearance of
programs to the same degree that RPN would.  Alternately, the
E-D proposal could be blessed in some fashion as "the interface
to use" for people who choose to use/provide this functionality,
so that at least independently written "safe" libraries could
have a decent chance of working together.

And, I have generally observed that the C++ committee does
whatever it chooses to do.  If they wish to invoke the "doesn't
fall within the scope and mandate" rule to reject a proposal,
they may, but they may choose not to invoke that rule.  I've
also observed that a large chunk of the world, for better or
worse, has signed on to use "C++" whatever the hell it finally
ends up as.  It might as well be improved as much as possible.

> It would mean C++ has fundamental flaw and should be
> scraped or ingored.

I think this is absolutely true (it has several fundamental
flaws, and should be scrapped or ignored) but I am certain that
it will neither be scrapped nor ignored.  Therefore, I prefer to
see as many flaws removed as possible.  I don't really think
that many will be removed, but there's no penalty for trying,
other than a little wasted time.

yours,

David Chase

David Chase <chase@michaelcenterline.com> wrote:
>Apparently some people think that the ideas behind "Safe C++" are
>radical and untested.

*sigh*

Reverse Polish Notation is neither a radical nor an untested idea.  A
proposal to change C++ expressions to use RPN syntax instead of a C
based syntax is a very radical proposal.  Similarily the ideas you say
are proposed by Safe C++ are in and of themselves not radical ideas.
Asking that it be incorporated into the ISO C++ standard is a radical
proposal.

>Nope, since there isn't a frozen standard for C++, or its libraries,
>C++ is what we get when the standard is done.

Not one of these stupid semantic debates again...  The ISO doesn't have
mandate to create C++, it already exists, it has a mandate to
*standardize* it.

>Proposals/suggestions cannot be rejected simply because they "aren't
>C++"...

Proposal can be rejected because they don't fall within the scope and
mandate of the committee.

>It is also difficult for me to understand exactly what "removing the
>C" means, or what's so horrible about it, assuming it is what I think
>it is.

It means you've wasted any advantage that might have been had basing it
on C in the first place.  It would mean C++ has fundamental flaw and
should be scraped or ingored.  I doesn't mean more junk should be added
to the language to try to hide the fact that it was ever based on C.

>The ability to refer to arrays and subarrays with what also looks like
>a pointer causes trouble for toolbuilders -- if this ambiguity were
>removed, it would be much easier to build these tools.  You could get a
>better garbage collector, and it would be easier to implement.  You
>could get built-in support for marshalling data structures (complicated
>ones, with cycles in them, and containing objects with "virtual member
>functions") to disk or over the net.  Your debugger could do a better
>job of displaying data (I know I get tired of trying to remember the
>incantation required when I want a "pointer" displayed like the array
>that it really is).  You could have tighter interface specifications.
>You could get (gasp!) run-time checking of array bounds.

I don't care about any of this.  If I want it, I know where to find
it.

>Back in 1990, when I worked at Olivetti Research Center, we had all
>these tools for a safe language, and they were implemented at a very
>low cost.  It took 5 people about 2 years to implement a compiler (with
>interface caching, for quick turnaround) and a pre-linker and an
>automatic dependency checker and an interpreter, for a language with
>exception-handling, garbage collection, run-time types, and a
>thread-safe library.

Great, you found your Nirvana, why aren't you happy?

>It ought to be easy in whatever "new" languages are designed, but it
>isn't in C++, it least not as it stands now.

Says who?  You've found your Nirvana, why mess with other languages?

>I realize that I must sound rather impatient and annoyed in this
>posting...

Not anywhere near as much as I do.

>... but it was clear how to "do safety" over 10 years ago, and it was
>clear what the problems were for C++ over 5 years ago.

Maybe there was a reason these "problems" weren't addressed.  If you
haven't already, read "The Design and Evolution of C++", by Bjarne
Stroustrup.

       Ross Ridge

I think that there has been some mischaracterization of
the Ellis-Detlefs Safe C++ proposal, and I have
not helped.  The proposal consists of:

 -- a garbage collector interface.
    (and, obviously, a garbage collector.
    Several are available.)  This appears to be
    some library calls, plus a new storage class
    "gc" to indicate allocation in the garbage-
    collected heap.

 -- an OPTIONAL safe SUBSET of the language
    Optional means optional.  Subset means nothing added,
    except for the pragma to flip the safety-checking
    switch.  Optional means you can use the garbage
    collector from unsafe code.

 -- Modifications to code generators to provide
    "code generator safety".

If you don't ask for it, you don't get it.  No existing
code needs to be rewritten. The compiler mods need not
be difficult (i.e., there are easy ways you can choose
to implement this, or more complex ways that should work
slightly better).  This is only incompatible with STL
in terms of style -- the template classes used in the
safe subset for array access can certainly support the
"*p++" syntax, if that is deemed to be a Good Thing.

If you want to read about it, you can get it (all 70 pages)
via anonymous ftp from:

  arisia.xerox.com:/pub/ellis/gc/gc.ps

This is

  -- not a fantasy
  -- not untested
  -- not a radical change
  -- not "removal of the C from C++"
  -- not an intolerable "burden on compiler writers".

Thanks for your patience.

David Chase, speaking for myself
CenterLine Software

In article <Cw3r2E.9r7@undergrad.math.uwaterloo.ca>
r-ridge@calum.csclub.uwaterloo.ca (Ross Ridge) writes:

>   Maybe there was a reason these "problems" weren't addressed.  If you
>   haven't already, read "The Design and Evolution of C++", by Bjarne
>   Stroustrup.

Dr. Stroustrup says in *The Design and Evolution of C++* that is it a
matter of *when*, not *if* garbage collection will be added to C++.
So, according to the source himself, something like "Safe C++" is not
a fantasy, but the future of C++ and should be seriously considered.

|>oug /\lan
   <nessus@mit.edu>