On Thu, 03 Mar 2011 14:46:41 +0100 Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:
On 03/03/2011 02:28, Chad Nelson wrote:
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.
You quote Dave's "Want Speed? Pass by value" article as motivation. [...]
Yes, I rediscovered that in the documentation last night, and I plan to reread the article to see whether it really applies or not, or if there are other reasons for it too.
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.
Consider a language like Python. All integers can be arbitrarily large, yet in practice, they rarely are.
Not the same case at all. XInt isn't a language, it's a library that's explicitly designed for very large numbers. If someone didn't need numbers larger than the built-in types can handle, they wouldn't use it.
Can your library allow me to choose a memory layout optimal for the application of my choosing? Probably not. How about you let me choose my own layout and let me interface with your algorithms?
If you want that sort of flexibility, you'd probably be better off with something like GMP. XInt isn't designed for that, and in my opinion, shouldn't be.
- I would quite like to get an interface to iterate the integer digit per digit or byte per byte.
Why?
- So that the library is easily extendable
What would you want to do to the internals of it that it doesn't already provide, and that I wouldn't be willing or even eager to add?
- So that the algorithms only require a range of digits as input if that's all they need, allowing them to work with arbitrary types of my choosing without having to copy or convert to your types
If it exposed the internal details of a number, then I'd never be able to change the way it works without breaking existing client code. That would be a much worse design.
[...] If the user provides a SIMD type as a digit, you'll get optimized SIMD code for free, for example, in a completely externalized way. Now *that* would be awesome. [...]
Yes, it would. But it would come at a cost.
- 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.
"sometimes-unneeded"? COW is disabled by default,
Disabled by default on *external* numbers. It's still used internally, where it's completely safe and much faster to do so.
and should never be used anyway, since it is a hack that only makes sense in a language without move semantics.
Which C++ still is, until C++0x is official and built into almost every platform's compilers. Which won't happen for a number of years yet.
And this is mostly a problem due to bad code design, there is no reason why you couldn't be rid of those two words in the non-COW case, and why you couldn't be rid of the buffer size in the fixed-width case.
Your opinion is noted.
Something else, I went through a code a bit, and I saw virtual inheritance. Just why do you need dynamic dispatch in a design where all information is purely static?
For the policy-based options. -- Chad Nelson Oak Circle Software, Inc. * * *