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-----
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
(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
> I'll have to review this incantation of the library when I get some free
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.
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk