Re: Garbage Collection - The Trash Begins To Pile Up

Francis Glassborow wrote:


Hmmm. When do we know this?? An easy example right out early 90's OO :
//in a header, a regular Interface
struct Interface{
       virtual void do_something() =0;
       virtual ~Interface(){}
};
typedef *unspecified* InterfacePtr;//what goes here???
InterfacePtr make(int choice);//factory

//in an implementation file
namespace {
struct Imp1:virtual Interface{
     std::ofstream f;
     void do_something(){
       if(!f) {
           std::ostringstring fname;
           fname<<"somefile"<<rand();
           f.open(fname.str());
           }
        f<<"write";
     }
};
typedef *unspecified* Imp1Ptr; //convertible to InterfacePtr
struct Imp2:virtual Interface{
     void do_something(){
        std::cout<<"write";
     }
};
typedef *unspecified* Imp2Ptr; //convertible to InterfacePtr
}//anon namespace
InterfacePtr make(int c){
   if(c)return Imp2Ptr(new Imp2);
   return Imp1Ptr(new Imp1);
}

and of course client code looks like

   InterfacePtr mystuff=make(0);
   mystuff->do_something();

So just what are we to use for InterfacePtr??
1. Interface * may leak of course, unless user does a manual delete.
Few designers choose this (sometimes useful for ABI reasons) --too easy
for user to forget to call, not exception safe to boot.
2. auto_ptr<Interface> would work. Cumbersome but at least we know code
is correct in all use cases that doesn't involve users playing with
guts of auto_ptr
3. shared_ptr<Interface> is the best bet of the off-the-rack standard
solutions, Code is correct in all use cases, with same "hands off my
guts" proviso. I could even make the implementation object static if I
wanted, by passing in a special deleter object.
4. Interface gc_pointer * or Interface^ or whatever the syntax is. It
works fine until unreclaimed file handles are all gone. However, we can
rest assured that if user played around with the raw pointer nothing
bad will happen.

To fix the problems with case 4, we take a cue from the Java/C# class
designers and put in a "close()" function in the interface, and tell
users that before they abandon the interface pointer they must call
close() just in case. But wait, isn't the point of "Automatic GC" that
we don't have to worry about WHEN we abandoned the object??? Ooops.
Just which thread gets to call "close()" What happens if we mess up and
call do_something() on an already close()'d object? What happens if the
user never users the return value?

So as long as we can rely on the user not doing something
self-defeating like auto_ptr<Interface>(mystuff.get()) then just what
advantage does option four provide?? Incorrect usage is almost certain
in all but the most trivial systems. Users are very unlikely to mess
around with internals of smart pointers--they are very likely to use
your close() method incorrectly.

Of course, if I were to throw in templates and such, the problems are
compunded. Establishing program correctness becomes a huge problem when
we involve "Automatic GC." And that is the core of the issue. Without
deterministic destruction, it is very very easy to make classes that
are not encapsulated-- "freeing a nonmemory resource" cannot be
encapsulated. And without encapsulation, making large correct system is
difficult at best. Automatic GC (that involves non-deterministic
cleanup) make many non-trivial program more error prone, not less.

The Java/C# communities already know this. There are pleny of
cumbersome workarounds in order to make "Automatic GC" work in those
languages -- finally clauses, using blocks, and so forth. A look at JMS
is a good exmple - it is replete with "close()" functions in the
interface, as a reminder that Java doesn't really have garbage
collection after all. Real life (not textbook) users of JMS have plenty
of finally, close() dispose overrides, and careful tracking of just
when close() is called, (whether the JMS provider needs it or not
internally) so that they may enjoy "Automatic GC." Naked new/delete
-- Interface ::close() whats the difference??

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]