- std::any and std::exception_ptr - 4 Updates
- Valgrind finds memory leak on ImVector<char[4096]>::resize(). Why? - 3 Updates
- Weird release build bug - 1 Update
- Dependecy Injection - 1 Update
- Onwards and upwards - 2 Updates
| johannes.gerd.becker@gmail.com: Dec 21 05:48AM -0800 N3804 proposes the introduction of std::any. Now, C++ already has an "any"-like type, namely std::exception_ptr. Semantically, after the introduction of std::any, exception_ptr will be a special case of std::any, namely a semantical std::any initialized by a caught exception. Wouldn't it make sense to make these two interoperate nicely? In particular, ** std::exception_ptr should be able to be converted into a std::any, as, currently, the only way of looking into an exception_ptr is re-throwing and catching immediately (please correct me if I am wrong). ** std::rethrow_exception should accept a std::any, throwing its contents (not the std::any itself). This would permit the preparation of a potential exception in advance and throwing it at a later point in time. Best regards, Johannes |
| woodbrian77@gmail.com: Dec 21 09:05AM -0800 > ** std::rethrow_exception should accept a std::any, throwing its contents (not the std::any itself). This would permit the preparation of a potential exception in advance and throwing it at a later point in time. > Best regards, > Johannes Run away from that stuff. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Paavo Helde <myfirstname@osa.pri.ee>: Dec 21 03:03PM -0600 johannes.gerd.becker@gmail.com wrote in > be a special case of std::any, namely a semantical std::any > initialized by a caught exception. > Wouldn't it make sense to make these two interoperate nicely? These look similar, but the mechanisms are different. Exception handling is all about derived classes and finding the catch handler of the correct base class type, whereas std::any does not recognize derived classes at all IIRC. Exception handling is also pretty slow. This probably means that the underlying implementations must remain pretty different. This does not mean that the conversion between two is not possible, only that it might not be so trivial. > contents (not the std::any itself). This would permit the preparation > of a potential exception in advance and throwing it at a later point > in time. This can be already done via std::make_exception_ptr(). Cheers Paavo |
| "Öö Tiib" <ootiib@hot.ee>: Dec 21 02:27PM -0800 > Semantically, after the introduction of std::any, exception_ptr will be > a special case of std::any, namely a semantical std::any initialized by > a caught exception. The named things are different: 'std::exception_ptr' is NullablePointer that has deeper knowledge of exception throwing mechanics and contains some sort of reference counting; 'std::any' is singular container of single object of whatever type. > ** std::exception_ptr should be able to be converted into a std::any, > as, currently, the only way of looking into an exception_ptr is > re-throwing and catching immediately (please correct me if I am wrong). May be there is come context where that may make sense. What is bad about re-throwing and catching? > contents (not the std::any itself). This would permit the preparation > of a potential exception in advance and throwing it at a later point > in time. That is already possible with 'std::make_exception_ptr' and 'std::rethrow_exception' so I see no value added. Also I think that it is the main point of 'std::exception_ptr' ... so someone who finds that constructing exceptions is expensive can throw same exception object over and over from potentially many threads and potentially at same time. For 'boost::any' I have found no purpose; on all cases I have found 'boost::variant' easier to use. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 20 11:21PM -0800 On Sunday, 20 December 2015 13:26:01 UTC+2, Nobody wrote: > update the simulation using numerical integration where "dt" is the time > interval between previous frames, and/or adjust the level of graphical > detail in order to obtain a reasonable frame rate. Indeed, the time-critical parts can not be stepped in debugger anyway since all sorts of timeouts may start to fire. > a debug build because the debug build runs so much slower than a release > build that it substantially changes the behaviour of the program, > resulting in Heisenbugs. OK. So instead of realizing that whatever they attempt is futile they start to write hand-optimized code to improve performance of debug build. Thanks. That makes sense now. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Dec 21 05:05PM On Mon, 2015-12-21, 嘱 Tiib wrote: > On Sunday, 20 December 2015 13:26:01 UTC+2, Nobody wrote: >> On Sat, 19 Dec 2015 08:06:59 -0800, 嘱 Tiib wrote: ... > OK. So instead of realizing that whatever they attempt is futile they > start to write hand-optimized code to improve performance of debug build. > Thanks. That makes sense now. Perhaps the right thing to do for the OP is to make debug builds, but modify them so normal versions of the standard library are used. Much of the templated code will be built without optimization, but at least it won't have extra range checks on iterators, operator[] and so on. Sounds like that should be possible -- although I have no experience with his toolchain. It's certainly possible with the GCC tools, since controlling the optimization level, the generation of debug symbols, and the libstdc++ settings, are separate settings. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Ian Collins <ian-news@hotmail.com>: Dec 22 11:06AM +1300 Jorgen Grahn wrote: > with his toolchain. It's certainly possible with the GCC tools, since > controlling the optimization level, the generation of debug symbols, > and the libstdc++ settings, are separate settings. I agree, both the tool chains I use (gcc and Oracle) allow fine control over both optimisation and debug settings. A good compromise is often "-g -O1" which give reasonable performance code with debug symbols. If your tools can't give you basic optimisation with debugging support, it's probably time to look elsewhere. -- Ian Collins |
| Juha Nieminen <nospam@thanks.invalid>: Dec 21 09:16AM > The weird thing is that if I uncomment those print statements, > then the function starts working! If adding debug printing seems to "fix" the problem (or in some cases introduces a problem), then in 99.9% of cases you are accessing memory you shouldn't be (ie. you are accessing an array out of bounds, or using a dangling pointer.) In complex code, rather than use raw pointers to arrays, you should wrap the pointer into a class (a bit like it were an iterator or smart pointer) and pass around copies of that class, and override operator[] and such. This introduces zero overhead to your code (at least if all the member functions are inlined), but has the advantage that you can temporarily add bounds checking to it, for debugging purposes. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Juha Nieminen <nospam@thanks.invalid>: Dec 21 09:08AM > constrained in the environments I program in, and if it can > change arbitrarily (with unknown bounds), it doesn't belong on > the stack anyway. Given that the size of the array needed is something like log(n) of the amount of data that the class processes, I don't think there's any worry about that. You'll much sooner run out of RAM (and disk space) before you run out of stack space. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Dec 20 11:38PM On 20/12/2015 18:25, Daniel wrote: >> here? > We're all waiting on the excellent Mr Flibble, as soon as he gives > the word, we're all on board. Brian's on-line code generator throws an exception if you present it with sausages so it still needs work I'm afraid. /Flibble |
| woodbrian77@gmail.com: Dec 20 04:54PM -0800 On Sunday, December 20, 2015 at 5:38:08 PM UTC-6, Mr Flibble wrote: > > the word, we're all on board. > Brian's on-line code generator throws an exception if you present it > with sausages so it still needs work I'm afraid. There's good reason to avoid bacon, ham and sausages - http://www.bbc.com/news/health-34615621 "Its report said 50g of processed meat a day - less than two slices of bacon - increased the chance of developing colorectal cancer by 18%." Brian Ebenezer Enterprises - "...That's what Christmas is all about, Charlie Brown." https://www.youtube.com/watch?v=DKk9rv2hUfA http://webEbenezer.net |
| 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