shoup at cs.nyu.edu
Wed Dec 17 12:43:51 UTC 2014
This all looks very good!
Marc Glisse <marc.glisse at inria.fr> wrote:
>On Mon, 15 Dec 2014, Victor Shoup wrote:
>> You could have the RAII object provide an explicit "kill" method,
>> which is called by the destructor or explicitly by TMP_FREE,
>> and have the object keep track of whether "kill" has already been
>> invoked on it. That should solve your first problem: in normal
>> execution, TMP_FREE will call "kill" before tests_end() has a
>> chance to complain, and during stack unwinding, the destructor will
>> take care of it instead.
>That's the easy way, and precisely what I am trying to avoid. I am
>that option as a last resort.
>> About C++03 vs C++11: I'd say for stuff like this, just go with
>> if that is significantly more convenient.
>Here I am trying to understand if it is pointing at a buglet in the C
>> Anyway, do you think there are other exception-related issues to
>> worry about?
>> Some other things to consider:
>> * Maybe all calls to abort should be replaced (conditionally, with
>> with throwing an exception (not just men alloc failures)
>Most, yes, but there aren't that many. The ASSERTs protected by
>WANT_ASSERT can remain as they are.
>> * What exception classes should actually be thrown? (I'm still
>> figure this out for NTL...)
>> One thing I would request: you only throw exceptions that are
>> in standard C++ header files, because right now, I don't expose
>> GMP interfaces in NTL header files, and it would be nice to keep
>it that way.
>> Failing that, I'd ask that you at least put GMP's exception class
>> in a separate header file...
>> Failing that, I can probably find a work-around (and maybe dumping
>> into some NTL header files is anyway not a big deal).
>> Anyway, it's something to think about...it would be a shame to get
>> and then have something trivial like this mess things up...
>> What I certainly don't want to do is catch, translate, and rethrow
>> in my interface layers: I just want to let GMP exceptions pass
>through my own code.
>> Anyway, it would be nice if we could coordinate on this just a
>> My current thinking is to throw bad_alloc for memory allocation
>> and runtime_error (possibly subclasses thereof) for everything
>> but I'm not sure.
>As a user I would just catch(...) and not bother further, but in any
>I was planning on using standard exceptions.
>> * Are there any other places in GMP that might cause exception
>> Any other type of global state, etc.?
>There might be global state in deprecated random functions, I don't
>there is anywhere else, but I don't know every part of GMP.
Sent from my Android device with K-9 Mail. Please excuse my brevity.
More information about the gmp-discuss