mpz_t C++ wrapper
Torbjorn Granlund
tg at swox.com
Thu May 1 14:08:00 CEST 2008
Heiko Wundram:
I know that mpz_class allows you to use the underlying mpz functions
directly, thus optimizing the temporary usage explicitly, but
especially with the ability to overload operators, I find this to be
quite cumbersome to read in the end (and not very C++-like), and
additionally this also generates convoluted code, because mpz_class
does not override operator mpz_srcptr or mpz_ptr (requiring you to
access the mpz_t pointer with get_mpz_t()), which is somewhat of a
PITA.
mpz_ptr and mpz_srcptr are internal types, and therefore no
user-visible interfaces should be made to them.
Heiko Wundram:
I plan on releasing the code under a BSD-style license anyway,
it's just that
Joerg Arndt:
At least release it also under LGPL, else the code is unlikely to
be ever part of GMP! TG might have more comments here...
Furthermore, code for GMP inclusion needs to be assigned to the FSF.
Heiko Wundram:
currently (because I only use _very_ limited parts of the wrapper
in my application) it's probably broken in one aspect or another,
and generally I can't actually say that there is any speed
improvement in a "real-world" application of it (simply because I
don't know what "real-world" terms look like). It shouldn't
perform worse than mpz_class, anyway (except possibly at
compilation speed), but I just want to escape all the NIH callers
before releasing it... :-)
Joerg Arndt:
Even if incomplete put it online (with a comment about the status).
People may well contribute if the thing is promising.
Hopefully TG comments some more, especially on what the priorities
to have a quality C++ wrapper are.
Improvements to the C++ wrapper would be welcome. Unfortunately, my
C++ knowledge is limited, so I cannot make any quality assessments of
various approaches.
It would be better to improve the existing wrapper, then throw it away
and replace it. Only if there is agreement among C++ experts that a
completely different approach is needed, a rewrite should be
considered.
--
Torbjörn
More information about the gmp-discuss
mailing list