On Wednesday, November 12, 2014 12:48:16 AM UTC+1, bluescarni wrote: > > OOM exception handling is gonna be hard to implement, as GMP does not > provide any mechanism to recover from memory errors. You can replace the > GMP memory management functions but the usual problem with that approach is > that you might be potentially interacting with other packages which might > also want to override the default functions. Another problem is that IIRC > throwing C++ exceptions from C is undefined (or maybe > implementation-defined?) behaviour. > Yes, Victor is aware that GMP error handling is a problem.
> > In any case, exceptions are the way to go when you program in C++. A > well-coded C++ program should state precisely what level of exception > safety the routines provide (no-throw, strong, basic), and how and what a > routine can throw. Ideally you would want strong exception safety always - > this is quite doable but sometimes for the sake of performance basic > exception safety is a good compromise. Of course anything involving move > semantics should be marked noexcept. Another typical suggestion is always > to use RAII patterns when coding routines that can throw - that way you are > guaranteed that any resource is properly cleaned up before exiting the > function through an exception. > > C++11 also has good support for handling exceptions in threads, including > transporting exceptions between threads. In particular, using an > std::future for managing the return value of (or the exception thrown > within) a thread is pretty handy. > > Cheers, > > Francesco. > > On 12 November 2014 00:05, Jean-Pierre Flori <jpf...@gmail.com > <javascript:>> wrote: > >> >> >> On Tuesday, November 11, 2014 11:55:49 PM UTC+1, Volker Braun wrote: >>> >>> What kind of error states are we talking about? divide by zero and out >>> of memory? >>> >>> Exactly, that is exactly the kind of stuff Victor mentioned. >> >> >>> IMHO a C++ library should just throw C++ exceptions, thats what they are >>> here for. If only for better readability -> less bugs. If you declare >>> methods with "except +" to Cython then they will automatically be converted >>> into Python exceptions, so its also very convenient for us. Pynac uses that >>> all the time. >>> >>> Pretty much the only potential downside are rumors that exceptions might >>> possibly hinder the optimizer. Though I've never seen that in a reasonable >>> benchmark. While that is certainly a possibility, it would just be an >>> optimizer bug. All reasonable C++ compilers uses a zero-cost model so its >>> at least as fast as handling / returning some error flag. What _is_ >>> expensive is when an exception occurs, but in C++ you are not supposed to >>> use exceptions for program flow like in Python. >>> >>> >>> >>> On Tuesday, November 11, 2014 10:15:44 PM UTC, Jean-Pierre Flori wrote: >>>> >>>> Dear all, >>>> >>>> As you must have noticed, Victor Shoup just released a new thread safe >>>> version of NTL. >>>> >>>> He also took the opportunity to ask me (and surely a bunch of other >>>> people) what would be expected from exception handling in NTL >>>> Currently NTL just prints something and then aborts. >>>> Note that we patch that in Sage to call one of our own functions and >>>> avoid aborting. >>>> I'm no C++ expert and don't usually play with exceptions, so I don't >>>> have anything that sart to say. >>>> But your comments/ideas/suggestions are more than welcomed. >>>> I can gather them and forward them back to Victor. >>>> >>>> Best, >>>> JP >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "sage-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to sage-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to sage-...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/sage-devel. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
