shoup at cims.nyu.edu
shoup at cims.nyu.edu
Wed Nov 12 17:07:43 UTC 2014
Maybe this belongs more in the dev mailing list, but...
I am not that familiar with GMP internals, but I spent this
morning looking around. It seems that memory allocation
for temporaries is done in a fairly uniform way, at least
within the mpn routines, which is what I'm most concerned with.
Temporary space seems to assigned to variables of type mp_ptr,
and the declarations are surrounded by TMP_DECL's, so are easy to
find. One idea would be to use a different type, mp_managed_ptr,
which in a C compile would just be typedef'd to mp_ptr, but in
a C++ compile, could be a class that has some kind of intelligence
built in to its constructors and destructors. This way, the
allocation routines could be designed to throw an exception,
and the destructors could release any allocated memory.
In addition, this class could provide automatic conversion
to mp_ptr, which means you should be able to use it just
like a plain mp_ptr in contexts that require one.
I've done this kind of C/C++ "retrofitting" before, and it can work
pretty well. The hope would be that the changes to the code
would be pretty mechanical (in this case, just changing the types
of temporary objects), and most of the work would be done by
the C++ compiler. Additionally, one would hope that this
does not add much run-time overhead in C++ compiles, and
zero overhead in C compiles.
I know I'm no expert on GMP internals, so I hope I'm not out
of line in making such suggestions. Also, I'm sure that there
are a number of details one would have to work out, and many other
things to think about.
Anyway, I'd be glad to discuss this further.
I do have some expertise in C++,
and would be willing to collaborate on this if anyone were
On Mon, November 10, 2014 1:43 pm, Marc Glisse wrote:
> On Mon, 10 Nov 2014, Victor Shoup wrote:
>> I know that this subject has come up before, but I was wondering if
>> are any updates.
> Not that I know :-(
>> I maintain a C++ library (NTL) that uses GMP for long integer
>> While NTL itself currently has very primitive error handling (print to
>> stderr and abort),
>> I'm investigating the possibility of making it use exceptions that
>> client code could
>> potentially deal with. One obsticle to this is GMP's error handling.
>> In my particular situation, NTL only uses GMP at the mpn layer, so much
>> the memory management is done by NTL (although I presume even the mpn
>> layer of GMP needs to allocate memory for temporaries).
>> So I'm wondering if there is any hope in the future of GMP offering
>> alternative error handling strategy? I know that GMP is "pure C",
>> but perhaps it could nevertheless be updated so that with judicious
>> use of macros, it could be compiled as a C++ library that would
>> throw exceptions in an appropriate manner.
> Being able to compile GMP as C++ is officially a goal, at least for
> testing purposes so we can more easily experiment with unusual limb sizes.
> Note that you can already tell GMP to use your allocator, which can throw
> exceptions, and if gmp was compiled with gcc -fexceptions, they will
> propagate. Some memory will leak in that case though.
> I am still planning to implement the second paragraph of this message:
> but as you can guess from the date you shouldn't hold your breath...
> Though it is simple enough that I may do it this winter.
> Marc Glisse
More information about the gmp-discuss