Code organisation of mini-gmp
nisse at lysator.liu.se
Mon Sep 10 13:45:47 CEST 2012
Torbjorn Granlund <tg at gmplib.org> writes:
> I think we should consider splitting it up into many files, basically
> one-function-per-file. The mini-gmp.c file would #include them all.
I agree this makes some sense. A few minor drawbacks: One may have to
make a few currently static functions non-static. And we may need a
mini-gmp-internal.h for internal macros.
> If we really want to keep mini-gmp as one file (why?) then we should at
> least play tricks with conditional inclusion for each and every
If it's possible to divide the features into pieces based on at most,
say, ten #defines available for users, then I think it would make sense
to keep at as a single file and manage dependencies manually at
But if it get's more complex than that, then I think it's preferably to
use a file per function and let the linker sort out the dependencies.
What tools are available for extracting the dependency graph for the
current functions in mini-gmp?
One difference in organization, compared to gmp, is that division
functions are organized as a general (but static) mpz_div_qr. Then the
various mpz_?div_* functions (and a couple of others) are single line
wrappers calling this function with different arguments. I don't think
there's much benefit in putting all of these wrapper functions in
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.
More information about the gmp-devel