[Corelinux-develop] Smart pointers.

[Ian C. <co...@st...>]

Now, I'm completely unfamiliar with CoreLinux++, so I might be out of line
posting here.  I apologize in advance if this is the case.

Anyway, I just read the SmartPointer draft.  The sample code in the Cons
section left me a little curious.  I use a homegrown reference counting
system in my own software with an interface that, IMHO, is a bit more
civilised than the one proposed in the SmartPointer draft.

I'll try explaining first.  If I leave everyone wondering, I'll post code
later.

My object class has a flag (specified in the constructor) that indicated
whether the object was allocated on the head and, thus, needs to delete
itself when it's reference count hits 0.  On top of that, it has a
reference count and a mutex (since, AFAIK, modifying the reference count
is non-reentrant).

Then, I have an object_ref<T> template.  The less obvious, more
interesting parts of this class are operator*, operator->, and operator T*
(i.e., an automatic cast to type <T*>).  So, given the declarations:

class Point : public object {
public:
  Point( bool dynamic ) : object(dynamic) { }

  void Draw();
  // ...
};

typedef object_ref<Point> Point_ref;

Point* p = new Point;
Point_ref pref = new Point(true);

The following statements are equivalent (because of operator* and
operator-> in object_Ref):

p->Draw();
pref->Draw();
(*p).Draw();
(*pref).Draw();

And so are these (because of operator T*):

if( p ) p->Draw();
if( pref ) pref->Draw();

Now, I don't follow the iterator examples SmartPointer draft, but using
STL containers, I often do things like:

typedef std::list<Point_ref> Point_ref_list;
typedef Point_ref_list::iterator Point_ref_list_i;

Point_ref_list pl;

pl.push_back( new Point(true) );
// etc.

for( Point_ref_list_i i = pl.begin(); i != pl.end(); ++i )
  (*i)->Draw();

In all these above examples, Point is a managed object (since it inherits
from object) and will be deleted when it's reference count reaches 0.
object_ref references/unreferences the object on construction/destruction
preventing the object from leaking.

Well, I thought this might inspire the SmartPointer development in
CoreLinux++.  I hope this is on topic.

For the sake of discussion, I'm thinking about changing the self-deletion
part of my object class to a system similar to Java's garbage collection.
A registry could track all dynamically allocated objects and a low
priority thread could pass over the collection periodically and delete any
whose reference counts are zero (i.e., collect the garbage).  The
advantage I could see of a system like this is that object destructors
wouldn't necessarily take time from the main thread (if this is
important... I'm not sure it is).  Disadvantages being that you'd be
wasting memory on the short term, you would need additional logic to
prevent an object from being destroyed after construction but before it is
first referenced, and it would take time (not a lot, but probably more
than I'm willing to spend on it right now) to implement.  But it's
certainly worth considering for an object management system in
CoreLinux++.

BTW, has any of that SmartPointer code actually been written?

Ian.


-- 
-----------------------------
http://www.stasis.org/~codic/