[PPL-devel] [Fwd: Re: Bug affecting mpq_class::get_num() and mpq_class::get_den()?]

Roberto Bagnara bagnara at cs.unipr.it
Wed Jun 12 07:37:45 CEST 2002


-------- Original Message --------
Subject: Re: Bug affecting mpq_class::get_num() and mpq_class::get_den()?
Date: Wed, 12 Jun 2002 10:25:03 +1000
From: Kevin Ryde <user42 at zip.com.au>
To: gerardo.ballabio at unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali)
CC: Roberto Bagnara <bagnara at cs.unipr.it>, Torbjorn Granlund <tege at swox.se>
References: <87k7p9bdqi.fsf at zip.com.au>	<20020610122024.C4790 at nettunio.mater.unimib.it>

gerardo.ballabio at unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali) writes:
 >
 > but I don't know very much about the internals of
 > mpz_t and mpq_t, and I'm not sure that such "symlinking" can be done

An mpq_t is just two mpz_t's, nothing more.  mpq_numref and mpq_denref
give pointers to the respective fields.  Would it work to cast to an
"mpz_class *" or "mpz_class &"?  Or would that be too nasty.

 > (actually, I looked into gmp.h, but I'm quite confused about mpz_t
 > being defined as "typedef __mpz_struct mpz_t[1];").

That trickery means when mpz_t is used to define a variable, it gets
space for one __mpz_struct, but if mpz_t is used as a function
parameter then it's just a pointer which is passed, giving "call by
reference".

 > Otherwise, I can only suggest to leave the code as it is, and to
 > change the documentation like this:

Thanks, I'll do that for now, and maybe put a note in the limitations
section about why.


-- 
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagnara at cs.unipr.it




More information about the PPL-devel mailing list