Re: Future of C++
on Tue Aug 12 2008, peter koch larsen <peter.koch.larsen-AT-gmail.com> wrote:
On 11 Aug., 12:28, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
gast...@hotmail.com wrote:
I agree. Selectable GC (in a library or requiring that classes are
derived from some sort of base class) would be nice extension. The
power of c++ is always that it spans low level and high level
constructs, but the high level constructs could be served better if
programmers weren't required to think about this.
I'm not so sure optional gc would work out very well. Suppose you're a
library designer - do you design it to work with gc, without gc, or
both? Doesn't this make it more difficult for the library designer, not
less?
More difficult in what way? I believe that all current code with
manually managed memory will continue to work in gc C++.
Only if nobody actually use the GC features. :-)
In C++ today we write classes that manage non-memory resources by
freeing them in their destructors, and we can have confidence that if
people follow "standard C++ coding practices" these resources will be
freed at particular times. Other programmers aggregate instances of
these classes into structures and can rely on a particular order of
destruction, and thus on those resources getting freed. These classes
often become the implementation details of other classes (think of the
mutex associated with a threadsafe class instance), and we can allow
clients to handle such classes without concern over when, or if, the
underlying resources will be freed.
In the committee we (at least some of us) could only think of three
possible purposes for GC in C++. The first and most obvious would be to
make it a legitimate standard coding practice not to call delete. But
once you start doing that, the guarantees given by destructors that
manage other resources no longer apply. Furthermore, the fact that a
class (indirectly) manages a non-memory resource can no longer be an
implementation detail. In fact, that "detail" now needs to ripple
upward through the documentation of all classes that contain such a
resource manager, so clients will know they can't be safely leaked. So
far, nobody has been able to come up with a reasonable coding practice
that avoids this problem. Until we have a workable programming model
for C++ with GC, I don't want GC in the language.
The other purposes were 1. making it possible for buggy, leaky programs
to run longer before running out of memory, and 2. certain kinds of code
(especially some lock-free algorithms) are very hard to write without
GC. In my opinion, neither of these possible benefits justifies
accepting the dangers described in the previous paragraph. On the other
hand, the benefit of being able to skip "delete" is so compelling that I
think people would assume they can do it.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]