Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!ncrlnk!ncr-sd!hp-sdd!hp-pcd!hplsla!jima
From: jima@hplsla.HP.COM (Jim Adcock)
Newsgroups: comp.lang.c++
Subject: Re: Support for movable objects in C++
Message-ID: <6590280@hplsla.HP.COM>
Date: 5 Oct 89 17:34:44 GMT
References: <1989Sep30.051559.20644@polyslo.CalPoly.EDU>
Organization: HP Lake Stevens, WA
Lines: 49

> schwartz:
> I may be missing something in this discussion, but isn't this exactly
> the problem that Glockenspeil's (public domain) Containers abstraction
> is supposed to solve?
> 
> One sets the file allocater to use whatever method one wishes (default
> is the stack (not movable), and doesn't worry about it after that.  It
> is the 'lock object's job to lock the object down to a known address
> when accessing it, otherwise the object can float freely.
> 
> Correctly, according to their documentation, this takes a long while to
> get used to (about 5 solid nights of work for me).  The documentation is
> a bit lean.  However, it does work nicely.
> 
> Please don't flame me if I missed the point of discussion.

Well, I'm not sure either, but I think there's several different points
floating around here.

My claims are: rather than making 'this' even more general [adding a level
of indirection] 'this' should be made even less general.  IE 'this' should
not be assigned to, and should not change.  --If we had it to do over I think
I'd like 'this' to be a reference and not a pointer at all.

Also, I claim you can 'easily' make a language that consistently uses handles,
[like Smalltalk] or consistently doesn't [like C++] but its hard to see how
one can mix approaches within one inheritence hierarchy [or DAG] without great 
difficulties or restrictions.

Also, in C++ it would seem to be easy to make a base class 'moveable_objects'
that would help support the moving needed by compaction, but then clearly
there's going to be restrictions on what one can do with those objects.
For instance, you'd probably want to prevent people from taking the address
of a 'moveable_object.'  Taking this approach would 'solve' the GC via
copying problem for objects of classes in this hierarchy.  You couldn't
use objects not derived from 'moveable_objects without reintroducing GC
problems.  And saying the 'moveable_objects' base class 'solves' the problem
is just saying for a particular range of problems the speed/space tradeoffs
implied by the restrictions imposed by 'moveable_objects' is acceptible.
Its probably very easy to find counterexample classes that will 'break' any
particular memory management approach.  Still, the ability to define a base
class 'moveable_objects' in unmodified C++ shows the language is up to the
task of meeting the needs of these people.

The preceading paragraph just really restates that memory management is 
best handled as a class related issue -- not as a language issue.
Unfortunately, its tough to find ways to use differing memory management
schemes and then be able to 'paste' together classes using disparent schemes
via multiple-inheritence.