[Corelinux-develop] Re: Corelinux-develop digest, Vol 1 #168 - 1 msg

[Ryan M. <rya...@te...>]

On September  6, 2001 01:01 pm, you wrote:
>
> Message: 1
> Date: Thu, 6 Sep 2001 10:45:26 -0400 (EDT)
> From: Ian Crawford <co...@st...>
> To: <cor...@li...>
> Subject: [Corelinux-develop] Smart pointers.
>
> 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.

Your not out of line at all. In fact Im glad youve taken the time to share 
your views. Im a compsci student in canada, and while Im not actually that 
helpful around here, I am interested in these sorts of design issues.

You should definately talk with Frank about your ideas. Hes a nice guy, but I 
think hes on vacation, since he has repsonded to my last email.

On a side note, I find it intersting that alot of what is being done to 
improve C++ is already implemented in C#. I cant wait until Ximian is done 
Mono...