Re: [boost] [xint] Fourth release, requesting preliminary review again

Subject: Re: [boost] [xint] Fourth release, requesting preliminary review again
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2010-06-02 15:24:40

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