Bitwise logic gmpxx.h problems

[Torbjorn Granlund]

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:
  >
  > __GMPP_DECLARE_COMPOUND_OPERATOR(operator&=)
  > __GMPP_DECLARE_COMPOUND_OPERATOR(operator|=)
  > __GMPP_DECLARE_COMPOUND_OPERATOR(operator^=)
  >
  > __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
  >> patch:
  
  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.

OK.

  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.

-- 
Torbjörn