Re: [boost] New Boost.XInt Library, request preliminary review

Subject: Re: [boost] New Boost.XInt Library, request preliminary review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-03-27 10:04:30

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

>>> first, to make 'xint::integer' consistent (if i were you) i'd make all
>>> public member functions non-member friend functions because 'int' and
>>> other fundamentals have no member functions
>>
>> Most of the non-operator member functions are there because n1692
>> required them.
>>
> i wasn't aware of it
> but my first statement still holds

'Fraid I have to disagree with it then. n1692 compatibility is more
important to me than trying to make it look exactly like a built-in
type. *Work* like a built-in type, yes... look like one, no.

> on the other hand looking at .net ints and double having 'toString()'
> and other member it's becoming a common practice

I don't see any viable reason to pretend that it's not a class.

> you may wonder what other people think about it

Certainly. And if more than a few people tell me that they agree with
you, I'll reconsider my position. :-)

>>> what about compile time fixed precision ints? like 'xint::fixed<128>'
>>> with '128' denoting number of bits (or bytes?)
>>
>> I don't see any obvious reason why that couldn't be implemented on top
>> of xint::integer. It should only require a fairly simple set of template
>> wrappers. I think it should be deferred until the underlying library
>> makes it through the review process though.
>
> in my view a templated version must be somewhat different
> as i figured out you use memory allocation for arbitrary precision
> objects

Rather difficult to do it any other way. :-)

> and one won't want to pay this overhead for simple (portable)
> int128 for example
> an 'xint::fixed<N>' (let's call it this way for now) must be a
> pod-like type which reuse all of the algorithms for 'xint::integer'

Then the fixed-size types will have to be implemented later, if there's
enough call for them. For this stage, I'm concentrating on
arbitrary-sized integers.

>> Also, I'm noting who made suggestions for the library, for an
>> acknowledgments page. Do you prefer to be known only as "Pavel", or do
>> you have a publicly-known last name?
>
> well, let it be just Pavel

As you wish. :-)

>> I'm aiming for the more casual user of large integers. [...]
> 
>> Don't think that those people don't exist -- the whole reason I started
>> writing it was because I was in the first camp myself. :-) I suspect
>> that people like that make up the vast majority of those who need a
>> large integer library.
>
> you read other's minds, don't you?

Only when it's convenient. ;-)

> i believe once you have state-of-the-art public interface for your lib
> you can easily switch to virtually any implementation
> so i don't see a problem here at all

I agree. The interface is generic enough that it should fit just about
any similar library out there.
- -- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuuEG0ACgkQp9x9jeZ9/wR86wCfd6kWCHVApjF7FDgNVllnfu2k
4TMAn030+PvvAnqHkVEQ0J/5Z55vZNbu
=l5JP
-----END PGP SIGNATURE-----