Hello, boost-request.
Date: Mon, 7 May 2007 12:00:04 -0400 From: "Jarrad Waterloo" <jwaterloo@dynamicquest.com> Subject: Re: [boost] Boost::Bigint header draft - suggestions are welcome!
I'll address last first. [snip] Multiple designs some utilize bit mask so the process can be repeated faster but I have only saw those on 'bigger ints'.
I see what you mean. It's added in a suggestion list, later all suggestions will be sorted on priority and some set will be chosen that will be a part of base functionality, and the rest will be postponed.
Now onto GMP big_int on the stack, I know of it but have never used it as I couldn't get it compiled on Windows and those with the knowledge are tight lipped. In any case, I thought they were a set of C functions that can work on int arrays whether heap or stack allocated. If that is the case why wouldn't it have a stack implementation!
You are right, GMP does provide a set of C functions that work on int arrays. But GMP does more actually. Among the things that are interesting to us GMP provides 2 layers of functionality. The first one is extremely low-level, works only with positive integers, is hard to use and may change in the future releases. So the current decision is as follows: The interface for the storage strategy IS developed, but it is used only for the default implementation. The GMP implementation still uses high-level GMP functions. Adding ability to use arbitrary storage implementation for GMP is in the suggestion list, so it will be reviewed together with the others and done after the base part is (by the way, I expect to finish the base functionality together with tests and documentation by the end of July, which will leave a month for implementing features in the list). Moving the storage implementation to the bigint_base template (thus forcing every implementation to be able to work with custom implementations) is a design decision which has not be made without thoughts. For now it is thought that this decision will be made when (if) GMP support will be implemented via a low level layer.
On a side note: I don't know how this will go over with other boost members. But could this be driver based. What I mean is the default implementation is the standard C++ approach which would always exist but if a faster one exists such as GMP that that is used. Does GMP versus standard has to be a part of the objects type? Just a thought but the important thing is to finally get an infinite int library.
There always will be a strategy-based class (bigint_base for now) with different implementations so the user can use the one he desires. Though there is a convenience typedef bigint (and there may be more when more implementations are developed), and this one can indeed depend on the existing implementations (like, #ifdef GMP_SUPPORTED #include <boost/bigint/detail/bigint_gmp_implementation.hpp> typedef bigint_base<bigint_gmp_implementation> bigint; #elif SOMEOTHERLIBRARY_SUPPORTED ... #else #include <boost/bigint/detail/bigint_default_implementation.hpp> typedef bigint_base<bigint_default_implementation> bigint; #endif ). Moreover, it likely will. By the way, I am assembling a proper suggestion list and expect to upload it to the SVN sandbox repository in several hours, and update it according to the input received from this mailing list and other places. -- Best regards, Arseny mailto:arseny.kapoulkine@gmail.com