Re: Future of C++
on Wed Aug 13 2008, "gast128-AT-hotmail.com" <gast128-AT-hotmail.com> wrote:
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.
It is not about freeing people of 'forgetting' calling delete,
Did I mention forgetting? I don't think so.
but when applications tend to grow the vast amount of objects becomes
a problem of itself.
Then you should reduce the number of objects.
Objects references to other objects in a higly dynamic configuration,
Those are usually poorly-architected programs. They tend to be
difficult to reason about and inefficient to boot.
it would really help if one could get help here from the environment.
So, what you're giving here is a motivation for being able to
legitimately not call delete. That's fine. My posting was concerned
with the technical goals of introducing GC into C++, whether they would
be addressed, and what problems they would cause.
The shared_ptr can help in this aspect, but it has 3 areas in which it
seems that GC does a better job:
1) shared_from_this() cannot be called from the ctor
Fixed in Boost (possibly the trunk), IIUC.
2) shared_from_this() cannot be called from the dtor
You want ressurection?
3) circualr references
These problems are by no means artificial: in our company I promote
smart pointers, and we ran in all above problems...
I see therefore GC just as (a small) next step. C has a huge advantage
over programming in assembly, but when programs grow, the c++ language
has advantage over c through its well defined constructor / destructor
model.
Yes, and so far, nobody has described a programming model for using GC
in C++ that doesn't undermine that advantage. That's probably why none
of the languages with built-in GC support dtors (and no, finalizers are
not the same thing).
And yes this all can be simulated in c, but in effect one is making a
framework what is already solved (better) by a programming language.
Note that programming problems aren't over if we have GC: it only
relieves some tasks (and introducing other problems as well)
I'm well aware of the potential value of GC. What I don't see is how to
fit that into C++.
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.
Is this the problem of keeping an object too long in memory (which GC
does with its non deterministic destruction).
No, not really. I thought I gave a pretty good explanation of the
problem above, and it's hard to think of anything to add to it that
would help you understand the problem. Maybe an example would help:
// this class is threadsafe!
struct queue
{
void push(int);
int pop();
private:
...
mutex m; // note: the fact that queue contains a mutex is
}; // an implementation detail; not part of the interface.
Today authors of other classes can use queues in their implementations:
struct simulation
{
private:
queue in; // note: the fact that this contains a queue is
queue out; // an implementation detail; not part of the interface.
}
When you introduce GC into the language, clients suddenly get the
freedom to intentionally "leak" most objects... but not mutexes, queues,
or simulations. [GC wouldn't call destructors (see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1943.pdf) and
even if it did, there's no guarantee that it would ever run. There are
myriad other reasons that destructors cannot be called from GC cleanup.]
So the fact that they manage a non-memory resource is no longer an
implementation detail of queue or simulation.
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,
I am afraid I belong to this kind of programmer...
Sorry to hear that.
--
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! ]