Bitwise logic gmpxx.h problems
tg at swox.com
Fri Jul 25 17:24:53 CEST 2008
Marc Glisse <marc.glisse at normalesup.org> writes:
On Thu, 24 Jul 2008, Joppe Bos wrote:
> I am not an experienced C++ hacker but the problem of these
> compiler errors are the following lines in gmpxx.h:
> __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator&=, __gmp_binary_and)
> __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator|=, __gmp_binary_ior)
> __GMPZZ_DEFINE_COMPOUND_OPERATOR(operator^=, __gmp_binary_xor)
> Replacing the double PP and ZZ by single ones solves the problem.
It seems mostly right, except that we now get (experimentally)
operator&=(double) which silently forwards to operator&=(unsigned long). I
don't really like that. I would prefer if it either generated an error
(which can be achieved by separating the float/double from the other
int/short/etc in the macros) or cast the double to a mpz_class (either
play with the macros to do this cast, or provide yet another overload for
the eval method).
Does mpz_a &= double work differently from mpz_a = mpz_a & double?
That'd be bad!
I suppose mpz_a $= double (for any operation $) should work like
mpz_b = double [using mpz_set_d]
mpz_a $= mpz_b
Is that not how it works now? In that case, we need to fix this.
>> As a C++ illiterate, I don't see why. But I had some joy with this
Looks quite similar to what I posted on 2007-12-29, except that it uses
the stack for the temporary object, which indeed seems much better.
The repetition of the code to "create a mpz_t large enough for a unsigned
long on the stack" makes it look like this could be turned into a macro.
Or maybe not (people might start using it too much). But anyway a few more
places (for instance mpq multiplication and wherever mpf_init2 has a
constant second argument) look like they could benefit from the same kind
of optimization, even though they are a bit larger.
That'd be a welcome contribution.
While I am looking at this code, I find it funny that there are always
several versions of eval that take their arguments in various orders and
have the same code, and the code is actually duplicated instead of having
one version with real code and the other versions that inline-call this
one with the arguments in the right order (or some macro game). It doesn't
really matter though.
Cleanups are always welcome. The gmpxx.h file could benefit from
careful code review, judging from its track record.
More information about the gmp-bugs