- C++ exceptions are broken. - 6 Updates
- generic memoization of pure functions? - 1 Update
| "Öö Tiib" <ootiib@hot.ee>: Mar 07 11:28PM -0800 On Tuesday, 8 March 2016 00:07:34 UTC+2, Mr Flibble wrote: > C++ exceptions are broken. These are not broken. Also calling virtual functions from constructor or destructor are not broken. Those may behave in not intuitive way for everybody but that does not make them broken. > downgraded into a less serious std::runtime_error exception if an > exception is thrown whilst evaluating the throw expression. This is a > nonsense. Code of some people often does something that other people consider nonsense. Destructor is implicitly 'noexcept(true)' unless destructor of any bases or members is 'noexcept(false)'. So a throw from 'noexcept(true)' destructor is transformed into call of 'std::terminate()' because there are no mechanism of stack unwinding. > Fix: if an exception is thrown whilst evaluating a throw expression then > std::terminate() is called. That 'std::teminate()' is more typically called because of throwing from 'noexcept(true)' functions by mine experiences. |
| see.my.homepage@gmail.com: Mar 07 11:42PM -0800 > downgraded into a less serious std::runtime_error exception if an > exception is thrown whilst evaluating the throw expression. This is a > nonsense. Fix: don't create throw expressions that are so complex that they might throw on their own. > Fix: if an exception is thrown whilst evaluating a throw expression then > std::terminate() is called. Nonsense. There is no difference between this: throw VERY-COMPLEX-EXPRESSION; and this: const my_exception_class & ex = VERY-COMPLEX-EXPRESSION; throw ex; In that second case (which can be further decoupled in space and time, if needed for the sake of argument) there is no way for the compiler to tell that it is the exception expression that is being evaluated and that it deserves special attention. Just to feed the discussion - the exception system might be based on something different than regular objects. For example in Ada exceptions are separate entities, which are declared, but not evaluated at run-time, and they are not "thrown" in the sense of passing some values around, but rather "signaled". Of course, it is still possible to mess the program up with exceptions popping out from destructors during stack unwinding. Then you can think about exception chaining (like in Java) as a possible solution to both problems above, etc., but then again you will have to face other problems like physical lack of memory for ever-growing exception objects, and so on. There is no universally good solution for this, with the exception (pun intended) of perhaps writing programs without exceptions at all. There is a reason why they are forbidden in some of the safety critical coding standards. -- Maciej Sobczak * http://www.inspirel.com |
| Juha Nieminen <nospam@thanks.invalid>: Mar 08 09:19AM > Fix: if an exception is thrown whilst evaluating a throw expression then > std::terminate() is called. You need to be able to re-throw exceptions. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Mar 08 06:31AM -0600 C++ exceptions are broken. As it currently stands a more serious std::logic_error exception can be downgraded into a less serious std::runtime_error exception if an exception is thrown whilst evaluating the throw expression. This is a nonsense. Fix: if an exception is thrown whilst evaluating a throw expression then std::terminate() is called. /Flibble -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |
| woodbrian77@gmail.com: Mar 08 07:10AM -0800 On Tuesday, March 8, 2016 at 6:40:14 AM UTC-6, Mr Flibble wrote: > Fix: if an exception is thrown whilst evaluating a throw expression then > std::terminate() is called. > /Flibble Maybe you should give asserts another shot. Brian Ebenezer Enterprises http://webEbenezer.net |
| scott@slp53.sl.home (Scott Lurndal): Mar 08 05:26PM >> std::terminate() is called. >> /Flibble >Maybe you should give asserts another shot. The use of assert is forbidden in my current project as far too draconian. Instead, we'll attempt to recover and if not possible, will log a message and disable or reset the subsystem affected and continue the simulation. |
| bartekltg <bartekltg@gmail.com>: Mar 08 12:00PM +0100 On 07.03.2016 09:21, Paavo Helde wrote: > integers<=x, meaning that if you calculate fib(2^32) you perform 2^32 > dynamic memory allocations for the map and consume several hundreds of > GB-s of memory. Not so nice. The whole idea of computing fibonaci number using 'linear' equation is not nice;-) This is only an exercise. > To be useful, the map should probably store only values for selected > points, like each fib(2^n), fib(2^n+1). Again, depends on the usage > pattern. http://mathworld.wolfram.com/FibonacciNumber.html equations 26 and 60. But if you use 29 instaad of 26, the whole memorization is almost useless. >> }; > This is much better than the first example in terms of memory > allocations, but still suffering from the memory explosion. In rare cases you need (almost) all values for n<N. I'm still not sure if this would be faster than O(log(n)) direct computation compared to random access to the array (cache). At least in this version wider index do not expand memory usage. > This seems interesting and most promising. > This looks fast enough to not > need any memoization. I do not see how to add memoization to if even if someone want to. The 'trajectory' is too sparse for memoization to do anything important. But it is still far for the best way. The symatric matrix use 6 multiplication, but this is not a any general matrix. One can use the relation d1 = d2+c and get 4 multiplication per level. If I really want, I can extract the equations (or loot to the wolfram page) and write it with 3 bignum-bignum multiplications per level: template <class bignum> pair<bignum,bignum> fibf_pair ( uint64_t x ) { //retrun fib{ x+1} and fib{x} if (x==0) return make_pair<bignum,bignum> (1,0); bignum F2n1, F2n, Fn, Fn1; tie(Fn1,Fn) = fibf_pair<bignum>(x/2); //n=x/2 F2n1 = Fn1*Fn1 + Fn*Fn; F2n = Fn* (2* Fn1 - Fn ); if (x%2==0) // x == 2n; x+1 == 2n+1 return make_pair(F2n1,F2n); else // x == 2n+1; x+1 == 2n+2 return make_pair(F2n1+F2n,F2n1); } template <class bignum> bignum fibf ( uint64_t x ) { return fibf_pair<bignum>(x).second; } But the matrix version is, paradoxically, easer to write. Additionally the matrix framework give us a way to compute F( a + b k ) for many k easily. I used it for another exercise: http://zimpha.github.io/2015/09/22/pa-2015-translate/#Fibonacci_(fib)_[A] Best Bartek |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment