Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Chad Nelson (chad.thecomfychair_at_[hidden])
Date: 2011-03-02 20:28:55

On Wed, 02 Mar 2011 18:18:33 +0100
Mathias Gaunard <mathias.gaunard_at_[hidden]> wrote:

> This is not a review, just a few comments from going through the docs 
> quickly.
>
> - XInt uses COW and passes everything by value. COW is useless in the 
> presence of move semantics (which the library seems to partially 
> implement), and passing by value everywhere unless you mean to copy is
> a bad idea.

Thank you for your comments. 

Boost.Move wasn't an accepted Boost library at the time I wrote that
code, so I didn't feel that I could rely on it. As such, it's only
there as an option at present. As it turns out, it's *still* not an
official Boost library (though through no fault in it or of its
author), so I think my caution is justified.

I don't recall the reason for passing by value offhand, but I believe
Boost.Move was part of it. I'll research that before the next update.

> [...] Also, it seems that the object always contains the copy count
> and a readonly boolean, which total 2 words, even if COW is disabled.

Eliminating sixteen bits of overhead, on an integer that is almost
always going to be larger than 64 bits (and often *much* larger), seems
to be a premature optimization at best.

> - from what I can see, the statement
>    xint::integer b = a0 + a1 + ... + aN;
> requires n copies of the underlying memory buffer, even though it is 
> possible to do zero copy without even using expression templates.

It could be optimized for such statements, yes. Can you provide a
real-world case where more than two or three integers would be summed
like that, and is common enough to justify the extra work and code
required for it?

> - unary operator+, operator++ and operator-- return a reference to
> the object. I don't think that's a good idea, since regular integers
> don't behave like this.

<http://stackoverflow.com/questions/465517/overloaded-increments-return-value>

> - I would quite like to get an interface to iterate the integer digit 
> per digit or byte per byte.

Why? If you need it for exchanging information with another system or
another program, the to_binary function should do the trick. If you're
looking to make changes to the internals of an integer_t without going
through its interface, it's not going to happen.

> - XInt cannot do SBO

A large-integer math library would be able to take advantage of SBO
only rarely, and every number object would have to carry around the
overhead, at least in all the SBO designs I've ever seen. If you were
complaining about sixteen bits of sometimes-unneeded overhead, I'd hate
to see how you reacted to, for instance, 128.

> - Fixed-width integers still store the size etc. Ideally, 
> xint::integer<fixed_size<32> > should have no more overhead than
> int32_t.

If the design were solely or even primarily fixed-width, I'd agree. As
it's first and foremost a variable-width system, and the fixed-width
behavior is secondary, I believe writing and maintaining code
specifically to eliminate a few extra bits for fixed-width integers
would not be justified.
-- 
Chad Nelson
Oak Circle Software, Inc.
*
*
*