I'm not sure why there's a constructor but not an assignment for an mpz_t. There's probably a good reason. Gerardo?
But yes, in any case we should drop the bool forms to avoid such subtle problems.
Roberto Bagnara bagnara@cs.unipr.it writes:
I did it again and this time is even worse. Without looking at the documentation I thought there should be an assignment operator for assigning an mpz_t to a class_mpz. So I did it, the compiler did not complain even with -Wall -W and then strange behavior started. The guilty is now the following line in <gmpxx.h>
__gmp_expr & operator=(bool b) { mpz_set_ui(mp, b); return *this; }Strictly speaking, I am not reporting anything new with respect to my previous message. What makes things worse is that I now realize that it is much easier to be bitten by this problem, since, IMHO, the user is somewhat legitimate to assume that mpz_t objects can be used to initialize/assign to mpz_class objects.
My revised proposal is that these two lines in <gmpxx.hh>
__gmp_expr(bool b) { mpz_init_set_ui(mp, b); } __gmp_expr & operator=(bool b) { mpz_set_ui(mp, b); return *this; }are _replaced_ by their analagous taking an mpz_t argument.
Here is a small test program that exemplifies the problem:
/////////////////////////////////////////////////////////////////////////// #include <gmp.h> #include <gmpxx.h> #include <iostream>
using namespace std;
int main() { mpz_class n; mpz_t m; mpz_init_set_si(m, 123);
// I thought I was assigning 123 to n... n = m; // ... but I was assigning 1! cout << n << endl; } ///////////////////////////////////////////////////////////////////////////
All the best
Roberto-- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it