-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/02/2010 12:02 PM, Marius Stoica wrote:
The next, and hopefully final, iteration of the Extended Integer library (a arbitrary-length integer math library) is now available in the
Great job!
Thanks!
Some comments
The documentation got a bit harder to read since it redundantly repeats the template arguments. Can something be done about that?
I've thought the same thing, and I don't yet know what to do about it. The only way I can think to fix it is to rewrite all of the functions as non-templates, purely for documentation purposes. I'm not fond of that solution; it means that the documentation would have to be at least somewhat removed from the implementation. The function signatures would have to be duplicated as well, which would increase the chances of them getting out of synch on any changes. I haven't ruled it out, but I'm hoping to find an alternative.
Related to that maby you can consider using boost parameter for the template parameters?
Would that make the documentation easier to read? I don't see any other benefit to using it here; there are only three optional parameters, and two of them have the same type (bool) so they couldn't benefit from Boost.Parameter's automatic deduction.
I think you should make clear in the documentation what threadsafe means. If it still only means that you can't use copies of xints across threads then some could still want to use them in multithreaded code.
That's still what it means. I've added further documentation on it, and modified the copy constructors to allow optional thread-safe copying of non-thread-safe objects; I've uploaded those changes to the sandbox now, if you want to see them.
From an user's point of view making nothrow just a template argument would make sense .
Would it? Though similar, they act very differently in the face of errors. The nothrow version also needs to support the Not-a-Number value, which requires a couple functions that don't make sense for the other types.
I consider using size_t for size in bits a little confusing/annoying. Maby you should typedef size_t bits_t; ?
I'm not sure I understand the complaint. size_t is the standard type for sizes. Wouldn't introducing a new type, which is just an alias for an existing and well-known type, be more confusing to people?
Also i'm interested wath do you think about the performamce when using small numbers. I've seen claims that gmp is "only 5% slower " than using plain ints in such cases. I'm thinking that such situations would be quite common in a lot of applications.
I hadn't considered that usage. I'm not sure how the speed compares to plain ints, but I'd be very surprised if it were anything near that fast. To make it faster, I'd have to eliminate some of its abilities. Or add assembly-language functions, which would break portability.
data_t seems quite a bloated class to me .
It's the central class of the entire library. Reducing its size would just mean moving the complexity somewhere else. Most of its size is due directly to the requirement that it support allocators, which I was told is necessary to be accepted as a Boost library. - -- 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/ iEYEARECAAYFAkwGr/UACgkQp9x9jeZ9/wQqDQCeIH3dAEv2QfkZT7fCEXRxshMy W4cAoI5e8YBSz5Twmrit0GT5RJr8MuKa =Axat -----END PGP SIGNATURE-----