-----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-----