on 27.03.2010 at 0:47 Chad Nelson wrote :
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 on the other hand looking at .net ints and double having 'toString()' and other member it's becoming a common practice you may wonder what other people think about it
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 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'
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
on 27.03.2010 at 7:02 Chad Nelson wrote :
I'm aiming for the more casual user of large integers. Somebody who needs a large-integer package to do specific calculations in his closed-source software, for example, and needs a Boost-licensed implementation a lot more than the highest performance. Or the person who needs an open-source large-integer package that's 100% portable, so he can compile it on some weird system cobbled together from old supercomputer parts. Or the guy who just needs a large-integer package to solve a particular mathematical programming puzzle and doesn't want the headaches of installing GMP, compiling it, and figuring it out.
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? 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
-- Pavel