Re: [boost] [xint] Design Question

Subject: Re: [boost] [xint] Design Question
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-17 12:28:32

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

On 06/17/2010 07:21 AM, Stewart, Robert wrote:

>> The options I've come up with so far, in order of my personal 
>> preference:
>> 
>> A: Make the unsigned option part of the fixed-length option, so it 
>> *can't* be specified separately. (The most elegant solution, but
>> perhaps not the most useful.)
>> 
>> B: Refuse to compile (or if I can't find a way to do that, 
>> instantiate) it, on the grounds that the combination can't 
>> logically be supported.
> 
> There are legitimate uses, I should think, so these options don't
> seem right.

I couldn't think of any legitimate reason for an unsigned
unlimited-length integer, given the inability to act the way the
built-in unsigned types do. That's why I asked.

>> C: Throw an exception if any calculation results in a negative 
>> number. (Not very useful, but logical because under the built-in 
>> types' unsigned rules, a negative number in an unlimited-length
>> library would be infinitely long.)
> 
> As I replied to another post on this question, it appears the correct
> behavior is for negative results -- for subtraction, anyway -- to be
> impossible.  That, of course, requires modulus behavior and your
> purpose, here, is to provide unlimited size, so there's no underflow
> possible.

Exactly.

> I'm not certain that an exception is the most reasonable recourse,
> however.  In code that never expects to produce negative results,
> even checking for a negative value is unwanted overhead.  Wouldn't it
> be better to simply permit such an operation to result in memory
> exhaustion?  That would get the attention of the program in short
> order without the tests and exception. 

The same way that a "bunker buster" bomb gets the attention of an ant
it's dropped on. ;-) But no, that would take extra code, as well as the
aforementioned "unwanted overhead" check. The library just isn't set up
to fail that way.

> You can also include checked modes -- a variation of a policy,
> perhaps -- that on negative values asserts, throws, etc.  That would
> leave the choice to the client.

That seems to be the consensus. So far it looks like there should be
four options:

* Modulus (only available on fixed-length types);

* Throw exception;

* Force to zero (for "saturation");

* Force to absolute value of number (possibly via a different function).

I suspect it'll be at least a few days before I can upload a version
with that feature, because I want to make some other improvements that
I've recently discovered are possible first.
- -- 
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/

iEYEARECAAYFAkwaTTAACgkQp9x9jeZ9/wRxZACfQgC5v88Uym8QGWzvoeVb5W6A
LIoAoMbvVW5mvhFuhKEGYZ6gX7/auli1
=nx0E
-----END PGP SIGNATURE-----