On Wed, 02 Mar 2011 18:18:33 +0100 Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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. * * *