Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-06 08:59:50

On Sat, 05 Mar 2011 19:15:02 -0800
"Jeffrey Lee Hellrung, Jr." <jhellrung_at_[hidden]> wrote:

>>> Regarding the former, it appears we still don't have a definitive
>>> benchmark comparing COW with move emulation, and one would be nice,
>>> but we can still predict how many deep copies each strategy will
>>> require for a given expression, and except in constrained situations
>>> where copies are never modified, I don't think COW gives any
>>> benefit. Sometimes COW is worse, since you can't explicitly transfer
>>> ownership.  Feel free to prove me wrong. [...]
>>
>> I'll be sure to report the results, either way.
>
> Looking forward to it.  It would also help to track the number of 
> allocations via the allocator or defining global new to ensure we get 
> the allocation statistics one expects.

Noted.

[...]
>>> I think a quick trip to wikipedia, as suggested by Robert, should
>>> convince you.
>>
>> That was one of the sources of my informal knowledge on the subject,
>> and at least the last time I looked, it explained nothing that I
>> could see about why O(n/2) == O(n).
>
> Right there in the definition: [...] Informally, what complexity
> estimates tell you is the relative growth in the running time of an
> algorithm as you increase the problem size.

I'd gotten the idea of it, but so many papers seem to include complex
formulas in the big-O notation that I thought it was standard to be as
precise as possible.

>>> You didn't really address my primary comment.  You can put lipstick
>>> on a pig, but it's still a pig.  You've just renamed make_unique
>>> into a constructor.  Is that a fair analysis?
>>
>> Yes. The complaint, as I recall, wasn't that the make_unique function
>> existed, but that it was part of the interface and meant to be used
>> or at least usable by client code. I didn't understand it either.
>
> So you didn't really faithfully address the complaint.  The interface 
> still has the make_unique functionality; you just put lipstick on
> it ;) 

It's an important ability, if the need for CoW is proven. Or to phrase
it different, without the lipstick, it would just be a pig. ;-)

> More importantly though...
>
> You (or anyone else!) don't necessarily have to accept anyone's or 
> everyone's suggestion.  If you feel like you have a compelling case
> to reject a particular request or do things a certain way, make your
> case, and your case and the opposing one(s) will be evaluated on its
> merits. [...]

If I had it to do over again, I'd lurk around this list for a year or
so and figure out which of the posters are most worth listening to,
*then* asked for the first preliminary review. I got a lot of feedback
that made no logical sense to me, but that (I thought) came from On High
and had to be implemented if I wanted the library to be accepted. I
originally assumed that I must not understand the concepts involved,
but looking back on it, I think in many cases the person offering the
opinion didn't have the specific experience with writing that kind of
library to realize why their suggestion wasn't necessarily a good idea.

>> Duplicating the code of that constructor function, with what I think
>> would be a single-line change, would be a superior design? I'm not
>> trying to be a pain, I'm honestly baffled at that assertion.
>
> In the interest of list traffic, I'm going to drop this line of 
> discussion, if you don't mind.  It's not important enough to belabor
> (sp?).

In the interests of maximizing development time, I'll accept that.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*