Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-03 18:02:24

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/03/2010 05:28 PM, Jeffrey Lee Hellrung, Jr. wrote:

>> I'm not sure that's really an improvement. The current design separates
>> throwing and nonthrowing for a reason; take a look at some of the
>> function implementations and you'll see why. Combining those would mean,
>> at the very least, an extra if statement in every function.
> 
> If by "an extra if statement" you mean an extra compile-time dispatch,
> then yes, but there wouldn't (or shouldn't, if done correctly) be any
> runtime overhead. 

Yes, once I realized that what I thought he meant didn't fit with what
you guys were saying, I did some research and realized what he really meant.

> I can see Marius' point of unifying all the integer classes under a
> single templated class xint::integer_t, but I imagine it will require
> quite a bit of refactoring. Whether to do this or not, and actually
> doing it if it should be done, is not the tallest nail right now (or
> is it?).

I've redesigned the whole blasted thing three times already. What's once
more?

(Yeah, that was a little cynical. I've really got to get back to paying
work, I've spent too much time on this already.)

>>> -add another pointer(probably the most serious issue, but you
>>> already have a 3 pointer indirection - maby you can make it so
>>> you can keep that ? )
>>
>> The fact that it takes any at all means that it would slow the library
>> down further. Just adding support for user-selected allocators slowed it
>> down by 2.3 to 2.5 percent, something I am not very happy about. I'd
>> need a *very* compelling reason to slow it any further.
> 
> Wait...adding support for custom allocators slowed things down over raw
> new/delete???  That doesn't sound right, though the 2~3% hit might be
> quality of compiler... [...]

It's the requirements of having a design that supports allocators, while
still working with concrete base classes so that the basic functions
don't have to be templates. I don't see any good reason to make
duplicates of every used function just because, for example, you want to
use three different fixed-bit sizes, which is what would happen if every
function was a template, in the design I thought I needed before.

With policy-based design, that probably wouldn't be a problem, though I
need to study it further and do some experiments to see what's possible
with it.

> I'll have to review this incantation of the library when I get some free
> time.

Please do. I'd really like to know exactly what you guys want it to look
like before I spend another month redesigning it yet again.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwIJnAACgkQp9x9jeZ9/wT+6wCfdokeTTI6zTPhd5eFWCCDWjbY
lMQAoJMbqh28SPFMcCmPXMKYS10CkG1S
=LpOf
-----END PGP SIGNATURE-----