Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-04 09:37:13
-----BEGIN PGP SIGNED MESSAGE-----
On 06/04/2010 09:15 AM, Scott McMurray wrote:
>> On the minus side, it looks like every function will have to be a
>> template, which is something that I tried very hard to avoid in
>> previous implementations. It'll be fast, but if a program uses more
>> than one combination of options, the size will increase greatly.
>> The saving grace, I suppose, is that there shouldn't be much need
>> to use too many option combinations.
> Would it not be possible to still keep the math parts in (internal)
> non-templated functions? It feels like the duplication should mostly
> be in the interface parts.
It's possible for a few of the primitives and more basic functions, but
anything that has to allocate a temporary integer_t needs the full-fat
version, or it won't know how to allocate and deallocate it properly.
Someone using the library for a security program would be put out to
discover that temporary variables ignored his stated allocator and
Secure preference, for instance.
> For instance, a single addition function could take 2 ranges of
> pointers and perform all the addition logic independently of the
> template parameters. Then the various templates would arrange the
> storage properly, call the function, and translate any errors
> appropriately (not that there'd be any errors for addition, though I
> suppose there might be a carry).
That would work for addition, subtraction, and multiplication. It
definitely wouldn't for division (which is more code than the
aforementioned three combined). I'm not sure which of the others it
would be possible for offhand, but I suspect it would be less than half
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, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk