Pierre Baillargeon wrote:
>
> James Kanze wrote:
> >
> > Programmers not thinking is a general problem, and I don't think that
> > any language changes can eliminate the problem completely.  With
> > John's suggestion, however, if the programmer doesn't think about this
> > one particular problem, either it is provably OK anyway, or he will
> > get a compiler error.  The programmer can continue not thinking by
> > using the smart pointer.
>
> I re-read John's message I realized we were talking about two different
> things. His post suggest a way to avoid having the user use unsafe
> pointers (bare pointers instead of ref-counted ones). My post was about
> a 1-1 relationship suddenly disappearing because it was severed from the
> other end.
>
> Note that what he his talking about can be 90% implemented now (I did).

     Yes, you can almost get it right by run-time checking.

> I believe all these requirements are not enforceable using the current
> language. We would need new keywords to restrict how a class can be
> instantiated and copied.

     Agreed.  That's what I'm arguing for.

     My point here is that the major languages developed after C++
all address the dangling pointer/memory leak problem in some automatic
way.  Java uses garbage collection, Perl uses reference counts, etc.
Memory leaks and dangling pointers remain one of the biggest
operational problems with software written in C++.  It's
unquestionably a serious problem with the language.  It needs to
be addressed in some way.

     Since performance is a higher priority in C and C++ than in
Java, Perl, etc., the solution chosen should not compromise
performance.  This implies doing as much of the job as possible
at compile time.  Classically, this issue is addressed at
run time, but I'm beginning to see the possibility of a compile
time solution.

     Between the STL and the recognition that good pointer usage
follows a modest number of standard patterns, we may have the tools
to prevent bad pointer usage without adding heavy run-time
machinery and its associated overhead.

     There's another advantage to addressing this at compile time.
The automatic-run time approaches to storage management have to
call destructors from garbage collection and pointer dereferences.
This results in unexpected concurrency and a new source of bugs.
This is partly why garbage collection add-ons to C++ never
caught on.

     Now that we have the STL, we have collections with reasonable
semantics, and we can use them to encapsulate some of these problems.
But not all of them.  I look at this as the next step beyond the STL,
and an issue to be addressed in the next major revision to C++.

     To summarize, what I'm proposing is that it seems possible
to have a modified C++ which is safe with regard to dangling
pointers and memory leaks, and without doing too much violence
to the language and the existing code base.

In genera, I'm proposing that

1) there be a language-level distinction between "owning" and
   "non-owning" pointers,
2) that ownership be encapsulated in a way such that when
   the owner goes away, the owned object must also go away.
   (Think auto_ptr, but better, with more compiler help.
   It's intended that this be the normal method of allocation,
   and that "new" and "delete" be reserved for use by
   collection classes and related storage management primitives.)
3) that both single ownership and multiple ownership be
   supported, the first without adding run-time overhead
   and the last via reference counts,
4) that local non-owning pointers be made both safe
   and efficient by compile-time checking which
   prevents them from outliving the owning pointer
   from which they were copied,
5) that additional data attributes,
   probably including "copy" and "delete" privileges,
   be added to the language to specify what a function can
   do with a pointer so that appropriate compile-time
   checking becomes possible, and
6) that some lookup-like mechanism along the lines of UNIX
   symbolic links be used to safely encapsulate pointer usages
   which can't be fitted into the standard patterns.

     I don't claim to have all the answers here.  And I realize
this is a rather abstract description.  But it's beginning
to look like there may be a solution in this direction.

     John Nagle
     Animats

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]