Bitwise logic gmpxx.h problems
marc.glisse at normalesup.org
Fri Jul 25 14:13:46 CEST 2008
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).
>> 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.
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.
More information about the gmp-bugs