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

[Roberto Bagnara]

-------- Original Message --------
Subject: Re: Bug affecting mpq_class::get_num() and mpq_class::get_den()?
Date: Thu, 13 Jun 2002 11:29:25 +0200
From: gerardo.ballabio at unimib.it (Ballabio Gerardo - Dip. di Scienza dei Materiali)
To: Kevin Ryde <user42 at zip.com.au>
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> <87adq1cpi8.fsf at zip.com.au>

Hi, I've done the "symlinking" and had mpq_class::get_num/get_den
return true mpz_class references (see attached files) -- but don't
like it very much.

The problem is, I had to change the implementation of mpz_class and
mpq_class: originally they just contained an mpz_t and an mpq_t,
respectively. Now mpz_class contains an mpz_t AND an mpz_ptr: the
pointer "normally" points to the mpz_t, but can also be "redirected"
to another mpz_t, in particular, to the numerator or denominator of
an mpq_t.
mpq_class contains an mpq_t AND two mpz_classes: this amounts to an
mpq_t, two pointers, and two mpz_t. That is, sizeof(mpq_class) is
more than twice that of mpq_t; furthermore, the two mpz_t are always
unused. I'd call such an implementation quite bloated.

Another possibility is to throw away the mpz_t, keeping just the
pointer, and to allocate it dynamically at the time of construction
(deallocation would be done by the destructor).
This is certainly better on technical grounds, but yields some
(small) overhead. However this overhead occurs just when constructing
and destroying, which should always happen outside of time-critical
portions of code.

Of course there is a third choice, that is, leave everything as is.

My "vote" goes to the second (dynamical allocation), but I would like
to hear your advice.

Gerardo


-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gmpxx.h
Type: text/x-c
Size: 167381 bytes
Desc: not available
URL: <http://www.cs.unipr.it/pipermail/ppl-devel/attachments/20020613/7fa2cac9/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpfrxx.h
Type: text/x-c
Size: 29774 bytes
Desc: not available
URL: <http://www.cs.unipr.it/pipermail/ppl-devel/attachments/20020613/7fa2cac9/attachment-0001.bin>