Jump to page: 1 2
Thread overview
Box data type
Sep 29, 2005
Derek Parnell
Sep 29, 2005
Burton Radons
Sep 29, 2005
Derek Parnell
Oct 15, 2005
Larry Evans
Oct 15, 2005
Regan Heath
How does Heath's RefPtr work? (was Re: Box data type
Oct 17, 2005
Larry Evans
Oct 17, 2005
Regan Heath
Oct 18, 2005
Larry Evans
Oct 18, 2005
Regan Heath
Oct 19, 2005
Larry Evans
Oct 19, 2005
Regan Heath
Oct 19, 2005
Larry Evans
Oct 19, 2005
Regan Heath
Oct 19, 2005
Larry Evans
Oct 19, 2005
Regan Heath
September 29, 2005
Why is a Box a struct and not a class object?

It sure makes generic coding more difficult.

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
29/09/2005 4:31:23 PM
September 29, 2005
Derek Parnell wrote:
> Why is a Box a struct and not a class object?

"there aren't any real opportunities for overloading, it's not mutable anyway, and many people will be repelled by the allocation".  Boxing necessarily resulting in an allocation is one of the reasons people reject C# out-of-hand.

> It sure makes generic coding more difficult.

Could you give an example?  I can't even begin to say anything without knowing what you're trying to do.
September 29, 2005
On Thu, 29 Sep 2005 13:13:37 -0700, Burton Radons wrote:

> Derek Parnell wrote:
>> Why is a Box a struct and not a class object?
> 
> "there aren't any real opportunities for overloading, it's not mutable anyway, and many people will be repelled by the allocation".  Boxing necessarily resulting in an allocation is one of the reasons people reject C# out-of-hand.

Okay, that makes good sense.

>> It sure makes generic coding more difficult.
> 
> Could you give an example?  I can't even begin to say anything without knowing what you're trying to do.

I was playing around with the reference counting class that Regan Heath supplied in an earlier post. In that case, the only things that could be reference-counted were class instances. In order to count strings or numbers I first tried to 'box' them without realizing that Box was a struct. Of course that failed. Modifying Regan's code to allow things other than objects was a PITA.

-- 
Derek Parnell
Melbourne, Australia
30/09/2005 6:39:35 AM
October 15, 2005
On 09/29/2005 03:46 PM, Derek Parnell wrote:
[snip]
> I was playing around with the reference counting class that Regan Heath
> supplied in an earlier post. In that case, the only things that could be
[snip]
> 
How can I find Regan's reference counting class, please?
Would this class contradict the statement:

  it is impossible to implement a useful smart_ptr in D.

from:

  http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/29135

?
October 15, 2005
On Sat, 15 Oct 2005 16:38:04 -0500, Larry Evans <cppljevans@cos-internet.com> wrote:
> On 09/29/2005 03:46 PM, Derek Parnell wrote:
> [snip]
>> I was playing around with the reference counting class that Regan Heath supplied in an earlier post. In that case, the only things that could be
> [snip]
>>
> How can I find Regan's reference counting class, please?

Attached.

> Would this class contradict the statement:
>
>    it is impossible to implement a useful smart_ptr in D.
>
> from:
>
>    http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/29135
>
> ?

That's debatable. It does 'work' but it's not as "fool proof" as you'd like it to be, in other words it is more likely you (by this I mean anyone using it) will accidently missuse it than a version written in say C++ (which allows you you overload the assignment operator)

For example, you must remember to 'assign' a new RefPtr with:

   RefPtr p = new RefPtr(old_one);

you cannot simply say:

   RefPtr p = old_one;

which means that when adding RefPtr's to an existing app you have to find all assignments of all references to the shared resource and replace them with constructor calls like those above. This makes it significantly more work, and significantly more prone to error.

Regan

October 17, 2005
On 10/15/2005 05:05 PM, Regan Heath wrote:
> On Sat, 15 Oct 2005 16:38:04 -0500, Larry Evans  
[snip]
>> How can I find Regan's reference counting class, please?
> 
> Attached.

Thanks!

[snip]
> anyone  using it) will accidently missuse it than a version written in say  C++ (which allows you you overload the assignment operator)
> 
> For example, you must remember to 'assign' a new RefPtr with:
> 
>   RefPtr p = new RefPtr(old_one);
> 
> you cannot simply say:
> 
>   RefPtr p = old_one;
> 
> which means that when adding RefPtr's to an existing app you have to find  all assignments of all references to the shared resource and replace them  with constructor calls like those above. This makes it significantly more  work, and significantly more prone to error.
> 
I'll certainly miss that from c++ :(

There are two questions I have about refcnt.d:


1) The reference count, declared as:

   int refs = 0;

at refcnt.d:9, is part of the RefPtr, not the
resource:

   Object resource = null;

at recfnt.d:10.  Hence, it's a detached refcount.
However, it's declared as a non-pointer type, and
so it cannot be shared between 2 RefPtr's pointing
to the same resource.  What am I missing?

2) There's the RefPtr field:

   RefPtr parent;

What is the purpose of parent?  I can't think of
a counterpart in c++ code.


Thanks for any clarification.

-best regards,
Larry
October 17, 2005
On Mon, 17 Oct 2005 12:21:38 -0500, Larry Evans <cppljevans@cos-internet.com> wrote:
> On 10/15/2005 05:05 PM, Regan Heath wrote:
>> On Sat, 15 Oct 2005 16:38:04 -0500, Larry Evans
> [snip]
>>> How can I find Regan's reference counting class, please?
>>  Attached.
>
> Thanks!
>
> [snip]
>> anyone  using it) will accidently missuse it than a version written in say  C++ (which allows you you overload the assignment operator)
>>  For example, you must remember to 'assign' a new RefPtr with:
>>    RefPtr p = new RefPtr(old_one);
>>  you cannot simply say:
>>    RefPtr p = old_one;
>>  which means that when adding RefPtr's to an existing app you have to find  all assignments of all references to the shared resource and replace them  with constructor calls like those above. This makes it significantly more  work, and significantly more prone to error.
>>
> I'll certainly miss that from c++ :(
>
> There are two questions I have about refcnt.d:
>
>
> 1) The reference count, declared as:
>
>     int refs = 0;
>
> at refcnt.d:9, is part of the RefPtr, not the
> resource:
>
>     Object resource = null;
>
> at recfnt.d:10.  Hence, it's a detached refcount.

The reference count is not part of the resource because that would require all countable resources to be derived from a common base, D has single inheritance so this would be very limiting. The idea was to keep the reference couting seperate from the resource itself. It is likely possible to create a mixin of some sort and derive a countable class from the class you want to count using the mixin. I am not sure what the benefit of that might be.

> However, it's declared as a non-pointer type, and
> so it cannot be shared between 2 RefPtr's pointing
> to the same resource.  What am I missing?

The count is shared using the 'parent' reference. This is why you must create a RefCnt using an existing RefCnt (and not the resource itself) in all cases besides the first. That is why I used a static ctor to create the initial RefCnt, because that must be used in place of the resource for the rest of the program.

> 2) There's the RefPtr field:
>
>     RefPtr parent;
>
> What is the purpose of parent?  I can't think of
> a counterpart in c++ code.

There likely isn't. This was the only way I could think of to share the reference count and ensure it was incremented and decremented at the appropriate times.

Note also 'auto' or explicit delete is required on all RefCnt references or the count will not be decremented when that reference is collected by the GC.

It is possible my implementation is naive. To be honest I am not an expert on reference counting, I created this as an example of what was possible in D, to show how deficient D was in this area.

Regan
October 18, 2005
On 10/17/2005 04:01 PM, Regan Heath wrote:
> On Mon, 17 Oct 2005 12:21:38 -0500, Larry Evans  
[snip]
> The reference count is not part of the resource because that would require  all countable resources to be derived from a common base, D has single  inheritance so this would be very limiting. The idea was to keep the  reference couting seperate from the resource itself. It is likely possible  to create a mixin of some sort and derive a countable class from the class  you want to count using the mixin. I am not sure what the benefit of that  might be.
Couldn't:

  int refs = 0;

be changed to:

  int* refs = null;

Then, change this(RefPtr rhs) to:

	this(RefPtr rhs)
	{
		resource = rhs.resource;
		refs = rhs.refs;
                (*refs)++;
	}

and eliminate:

  RefPtr parent;

altogether?
October 18, 2005
On Tue, 18 Oct 2005 11:32:49 -0500, Larry Evans <cppljevans@cos-internet.com> wrote:
> On 10/17/2005 04:01 PM, Regan Heath wrote:
>> On Mon, 17 Oct 2005 12:21:38 -0500, Larry Evans
> [snip]
>> The reference count is not part of the resource because that would require  all countable resources to be derived from a common base, D has single  inheritance so this would be very limiting. The idea was to keep the  reference couting seperate from the resource itself. It is likely possible  to create a mixin of some sort and derive a countable class from the class  you want to count using the mixin. I am not sure what the benefit of that  might be.
> Couldn't:
>
>    int refs = 0;
>
> be changed to:
>
>    int* refs = null;
>
> Then, change this(RefPtr rhs) to:
>
> 	this(RefPtr rhs)
> 	{
> 		resource = rhs.resource;
> 		refs = rhs.refs;
>                  (*refs)++;
> 	}
>
> and eliminate:
>
>    RefPtr parent;
>
> altogether?

Perhaps. However, you need to synchronize access to that integer. My code synchronizes on the class, you would have to use some sort of InterlockedIncrement function or similar.

Regan
October 19, 2005
On 10/18/2005 03:08 PM, Regan Heath wrote:
> On Tue, 18 Oct 2005 11:32:49 -0500, Larry Evans  
[snip]
>> Couldn't:
>>
>>    int refs = 0;
>>
>> be changed to:
>>
>>    int* refs = null;
>>
[snip]
>> and eliminate:
>>
>>    RefPtr parent;
>>
>> altogether?
> 
> 
> Perhaps. However, you need to synchronize access to that integer. My code  synchronizes on the class, you would have to use some sort of  InterlockedIncrement function or similar.

Ah!  I hadn't considered synchronization.  But then couldn't the
refs be encapsulated in another class to do this:

class RefPtr
{
  RefPtr parent;
  Object resource = null;

  class RefCount
  {
    int num_refs = 0;

    int increment()
    {
       //sychronized increment
    }

    int decrement()
    {
       //synchronized decrement
    }


  }//end RefCount class

  RefCount refs = null;

  ...

}//end RefPtr class

OK, now I'm probably showing my ignorance of how D differs from C++.  My
understanding is that, since RefCount is a class, it's allocated on
the heap.  Also, based on the original code, which contained:

  resource = res;

I'm assuming that the assert in the following code passes:

  this(RefPtr rhs)
  {
    resource = rhs.resource;
    refs = rhs.refs;
    refs.increment();
    assert(refs is rhs.refs);
  }

IOW, the reference count is shared between rhs and this.
« First   ‹ Prev
1 2