speed of mpz_odd_p and lazy allocation

[Gabriel Dos Reis]

On Wed, Aug 15, 2012 at 2:21 PM, Marc Glisse <marc.glisse at inria.fr> wrote:
> 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...)

My observation wasn't meant to be a criticism.  Just
that of a mostly quiet observer.

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

I suspect the real issue is whether the inherent complexity can be
hidden from users...

>
>
>> My suspicion is that newer versions of C
>> will soon include something similar :-)
>
>
> constexpr in C? Hmm...

well, it would probably be called something like _Constexpr or something
like that with a few incompatibilities but I would not be surprised. :-)

-- Gaby