speed of mpz_odd_p and lazy allocation

[Marc Glisse]

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 
problem...)

> 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...

-- 
Marc Glisse