mpz_t C++ wrapper

Torbjorn Granlund tg at
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

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


More information about the gmp-discuss mailing list