documentation of mpz_ptr and mpz_srcptr
tg at gmplib.org
Tue May 26 14:26:42 CEST 2009
Marc Glisse <marc.glisse at normalesup.org> writes:
I noticed, trying for once to write code that uses only documented
interfaces, that mpz_ptr is purposedly undocumented. However, it can
be useful. I have seen code that could have used it but ended up
working around this lack, for instance using one more level of
indirection (mpz_t*). One piece of code was something like:
if(test) c=&a; else c=&b;
... code using *c ...
Obviously this works, and there are other ways to make it work, but it
would be nicer (although it kind of hides the aliasing) if I could
if(test) c=a; else c=b;
... code using c ...
Am I missing some obvious alternative for mpz_ptr? Otherwise, is there
really a risk that mpz_ptr will break in a future release?
I think I need stronger arguments for introducing a new type than that
you can omit a measly ampersand in assignments. :-)
I admit that I also find it clearer to use mpz_ptr and mpz_srcptr
instead of mpz_t and const mpz_t for the argument and return types of
I am not sure I agree. Using the same type for formal and actual
parameter is probably clearer for most users. Understanding the
semi-compatibility of mpz_t and mpz_ptr requires more insight into the
wonders of C and C++ than most users have.
More information about the gmp-discuss