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 _______________________________________________ PPL-devel mailing list PPL-devel@cs.unipr.it http://www.cs.unipr.it/mailman/listinfo/ppl-devel