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-----
>>> 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
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
>> 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.
Oak Circle Software, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (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