Re: [boost] [XInt] Some after thoughts

Subject: Re: [boost] [XInt] Some after thoughts
From: Simonson, Lucanus J (lucanus.j.simonson_at_[hidden])
Date: 2011-03-10 17:44:26

Jeffrey Lee Hellrung, Jr. wrote:
> On 3/10/2011 11:14 AM, Simonson, Lucanus J wrote:
> [...]
>> Throughout this review I never saw anyone make the case for COW that
>> seems most relevant to me. 
> 
> Agreed.
> 
>>  Most usage of built in integer types in a generic context uses pass
>> by value explicitly rather than using the type traits. 
> 
> I'm guessing you mean call_traits, right?

Yes, I misspoke.

>>  This means that libraries like ratio and random or whatever else
>> will probably pass multi-precision integer types by value in all of
>> their functions.  
> 
> Yes, that's unfortunate.
> 
>>  COW is the only way to mitigate all that copying around.
> 
> Well...not the only way, but the least intrusive way.

I was thinking of ways that can be accomplished within the scope of the xint library itself without forcing everyone elses code to change.

>>  Perhaps this was so obvious or covered so early in the review that
>> it went unstated recently, but I think ET on COW enabled (or
>> COW+move enabled) objects is a perfectly valid design choice.  
> 
> I agree that the above example is actually a valid *and* compelling
> argument for CoW.
> 
> However, as I've stated before, I believe any CoW infrastructure would
> be best built on top of a non-CoW infrastructure, since non-CoW indeed
> has its own advantages, and building a non-CoW infrastructure on top
> of 
> a CoW infrastructure likely compromises many of the non-CoW
> advantages. 

I hate reference counting schemes as a general rule because they always seem so reasonable and straightforward at the beginning but tend to lead to a lot of problems in the end.  I could write a country western song about reference counting, broken hearts and bitter regret....  Even so, there is a good rationale for having it in this case.  However, I would prefer as a design consideration to separate out COW from the integer class and perhaps have a boost.cow library that allows you to declare COW handles to objects of any type rather than tightly coupling that general capability to the implementation of this library.  That way people can use COW or non-COW (perhaps move enabled) infinite precision integers by composition, but it does complicate the ET system if it needs to handle COW wraped handles to ininite precision integer objects, but that complication is well within the scope of what proto can easily handle, so I'm not concerned.

Regards,
Luke