speed of mpz_odd_p and lazy allocation
marc.glisse at inria.fr
Wed Aug 15 21:21:32 CEST 2012
On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 9:45 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
>> Note also that I am not going as far as some propositions for the future C++
>> std::integer type, which may require construction from int to be a
>> compile-time operation (no dynamic allocation).
> I think that is very reasonable approach for most C++ in production use
> today, which still use C++98 or C+03.
(I started this discussion specifically to improve the move constructor,
in C++11 then, so if my thinking is too C++98-like, there is going to be a
> It is also worth thinking (in longer term) about C++11 with a programming
> model that includes far more compile-time computation than
> previous C++ versions did.
I think we should first see what we can do without breaking the current
mpz_t format too much (in the longer term, that format is certainly not
what C++1y implementations will adopt, but then mpz_t can coexist with
other types). Allowing the pointer to point to nothing or a dummy limb is
not that bad. Reusing the bits of the pointer to directly store an integer
when some condition on size and alloc is verified is already much worse
(though it would be useful, and allow some limited compile-time
computation). Changing the struct...
> My suspicion is that newer versions of C
> will soon include something similar :-)
constexpr in C? Hmm...
More information about the gmp-devel